I own a piece of hardware, so I can do what I want to it. Out there, there is software, which I have to figure out how I'm going to trust, whether it's e.g Windows and I'm trusting that whole way of doing things, or Linux and that other whole way of doing things.
Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
31–40 of 142 posts
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#32Earlier quoted context omitted.
It’s something about hardware companies writing software. The motherboard itself may be excellent, but the BIOS/UEFI/ACPI tables will be horrible. Meanwhile you look at a company like Oxide that is a software company at heart, and their equivalents are so much better. Like someone actually designed it so that when humans write the software it will still be secure.
> It’s something about hardware companies writing software. I've seen enough examples of that, to suspect there's some truth to it, and wonder why that is... Speculation: * Systems programming is hard, and systems programmers who are familiar enough with the kind of target hardware are even more rare. A company might decide to hire a hardware engineer who can code, rather than a systems programmer software engineer w…
Same person thinks I'm literally paranoid for splitting home, IoT, and Security cameras into separate networks... despite the cameras and dvr being the banned/recalled costco ones.
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#33> The root cause of this bug, once again, lies in the unsafe handling of NVRAM variables. Sheer incompetence, in other words.
UEFI variables or not: who in their right mind serializes raw pointer values to any kind of storage (network, disk, nvram, ...)? Why is it that the most security-sensitive areas are ravaged by the sloppiest programmers and the most negligent managers and business types? I'd like to understand the economics and the psychology behind it.
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#34Earlier quoted context omitted.
The problem here is that the signature doesn't do anything for you . Suppose you want to be assured of the software running on your machine. You go into the firmware, point it at your boot loader and say "only this one". It makes a hash of the boot loader and refuses to use any other one until you change the setting, which requires your firmware password. Your boot loader then only loads the operating systems you've…
>Suppose you want to be assured of the software running on your machine. You go into the firmware, point it at your boot loader and say "only this one". It makes a hash of the boot loader and refuses to use any other one until you change the setting, which requires your firmware password. Your boot loader then only loads the operating systems you've configured, and so on. What if you need to update the bootloader? >T…
Then you boot the system from the existing bootloader, causing the booted system to be trusted to supply a new hash.
> TPMs can do remote attestation without signatures just fine, by measuring the hash of the bootloader.
If there are no private keys in the TPM from the factory then there is nothing for a third party to force you to sign the hash with, as intended.
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#35Earlier quoted context omitted.
The problem here is that the signature doesn't do anything for you . Suppose you want to be assured of the software running on your machine. You go into the firmware, point it at your boot loader and say "only this one". It makes a hash of the boot loader and refuses to use any other one until you change the setting, which requires your firmware password. Your boot loader then only loads the operating systems you've…
> The problem here is that the signature doesn't do anything for you. For your own personal machine, sure. But say you're a sysadmin in a company that has thousands of units. Suddenly, a CA infrastructure is much more appealing than having to deal with component hashes.
Also, the concern is that the system comes from the factory with private keys the owner doesn't have access to, allowing the device to defect by informing on them to a third party. Keys installed by the owner rather than the manufacturer are fine, and then such keys also wouldn't be trusting random third party code either.
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#36Earlier quoted context omitted.
I refuse to endorse any mindset where my Personal Computer unquestionably running my code could be considered a bad thing.
You're conflating UEFI with secureboot. Moreover all the secureboot implementations I've seen allow you to either disable it or enroll your own keys.
Here you go — now you have. Thank ${DEITY} for exploits!
https://wiki.ubuntu.com/ARM/SurfaceRT#Secure_Boot
https://openrt.gitbook.io/open-surfacert/common/boot-sequenc...
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#37I still genuinely struggle to understand the advantage of UEFI/Secureboot whatever over BIOS. I own a piece of hardware, so I can do what I want to it. Out there, there is software, which I have to figure out how I'm going to trust, whether it's e.g Windows and I'm trusting that whole way of doing things, or Linux and that other whole way of doing things.
Apart from way nicer boot menus and bootloader setup?
In a security context, it prevents a whole host of attacks, it's clearly an advantage and a much needed progression.
> Out there, there is software, which I have to figure out how I'm going to trust,
Yes, and with secureboot, if you guess wrong, that malicious software can do less damage than it otherwise could.
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#38I still genuinely struggle to understand the advantage of UEFI/Secureboot whatever over BIOS. I own a piece of hardware, so I can do what I want to it. Out there, there is software, which I have to figure out how I'm going to trust, whether it's e.g Windows and I'm trusting that whole way of doing things, or Linux and that other whole way of doing things.
You can turn it off, or make it into trust-once and sign your own bootloader, and avoid the risk of bootkit getting installed ever, except with exploits like these.
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#39Earlier quoted context omitted.
why not secure boot with your own keys? ... granted, effectively removing Microsoft keys is a pain on some consumer devices, but still easier than this
My first encounter with UEFI turned out to be quite expensive because UEFI was way too new and easy to brick. I guess things are better now, but toying around with this might still be a risk not worth taking as a consumer.
A bit. But compared to BIOS is still crap. The main advantage of UEFI over BIOS is that it offers RCE. /s