I wish the hardware industry went more in the direction of the State Considered Harmful paper:
https://blog.invisiblethings.org/papers/2015/state_harmful.p... https://www.qubes-os.org/news/2017/07/08/toward-a-reasonably...
Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
111–120 of 142 posts
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#112Earlier quoted context omitted.
> Secure boot requires that the bootloader match a hash derived from a TPM-stored key. This isn't even slightly accurate. Secure boot does not rely on TPM keys on any way.
Huh, I don't know why I thought it did. Looking into the link below briefly I see it uses a PKI scheme with CAs. https://learn.microsoft.com/en-us/windows-hardware/manufactu... So I guess if you provide a key for the bootloader, the firmware will sign it when it's in setup mode? I guess that private key is embedded directly in the firmware then? I presume that's made invisible once control is handed to the bootloader…
No, the firmware never has any private keys. You sign offline with a private key and provide the public key to the firmware. All further bootloader updates are signed with the same key and require no additional firmware configuration.
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#113Earlier quoted context omitted.
Unless your BIOS/UEFI supports full disk encryption unlocking of hardware-encrypted Opal drives, you will always have an unencrypted bootstrap process at early boot from the disk. That unencrypted bootstrap process can be modified by anyone with access to the disk, physical or remote. Theoretically, someone can inject a keylogger into the process and exfiltrate your encryption key's password, or a process that waits…
https://news.ycombinator.com/item?id=44246281
Ah, I thought you were replying to the full quote
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#114Earlier quoted context omitted.
Theoretically you hook up your whole disk encryption to your secureboot and it protects you against "evil maid" attacks. But yeah I'm pretty sure in practice it's about making it harder to install Linux or watch imported Blurays.
I suspect the actual reason is a lot more banal, it's enterprises asking for it. People who own fleets of devices and need to keep them secure don't care about homegrown Linux distributions, they want to minimize the fallout from that one employee installing the "FlashPlayer update" again. Those are the people driving the concerns of Microsoft and computer vendors.
If by 'enterprises' you mean Disney and Sony, I fully agree.
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#115Earlier quoted context omitted.
Secure Boot is closed and not auditable.
Not so, the reference implementation is open source and incorporated into Coreboot, for a long time now.
The reference implementation is not the same as knowing which code runs on "your" hardware and having all keys from "your" hardware. If you are protected by a steel door but you don't have the keys, you are not safe, you are imprisoned.
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#116Earlier quoted context omitted.
Some kind of secure enclave is necessary to prevent brute force attacks. Allows simple PIN unlock for users.
> Some kind of secure enclave is necessary to prevent brute force attacks. Eh maybe, what's the realistic threat model here? 99.9% of the time someone stealing a laptop isn't going to know or care what's on it, they'll just wipe it and sell the hardware. And in the rare case where you're seriously concerned about a competitor or spy making a targeted attack, you'll have a password policy where you're not using someth…
The supposed attack scenario is that the laptop is returned in a trojaned form with a kernel-based keylogger. The usual counterargument is that the laptop might be as well returned with a hardware-based keylogger.
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#117Earlier quoted context omitted.
Everyone says that till they get remote rootkitted in ane exploit chain that uses a moderate rated cve.
More like: go see fusee gelee. Nvidia didn't do boundary checking on their usb DFU boot and it compromised every nintendo switch up to that date, and (i expect) got all nvidia shields' level 2 widevine keys revoked.
For those who are are not asking and are lazy.
https://nvd.nist.gov/vuln/detail/cve-2018-6242
and
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#118Earlier quoted context omitted.
> How does the system know whether the new bootloader is legitimate or not? However it wants to. Maybe the existing bootloader (chosen by the owner rather than the vendor) or the OS it loads has its own signature verification system for update packages, like apt-get. Maybe the OS downloads it from a trusted URL via HTTPS and relies on web PKI. Maybe it uses Kerberos authentication to get it from the organization's ow…
The situation you're protecting against is one where someone who compromises the OS can make that compromise persistent by replacing the bootloader. That means you can't place any trust in any component after the bootloader, since an attacker could just fake whatever mechanism you're enforcing. > The point isn't which device has the keys, it's that it shouldn't contain any from the factory. Nothing good can come of i…
> The situation you're protecting against is one where someone who compromises the OS can make that compromise persistent by replacing the bootloader. That means you can't place any trust in any component after the bootloader, since an attacker could just fake whatever mechanism you're enforcing.
Isn't that kind of pointless?
Suppose the attacker gets root on your OS, i.e. what they would need to supply the firmware with a new hash. That OS install is now compromised, because they can now change whatever else they want in the filesystem. If you boot the same OS again, even using the trusted bootloader, it's still compromised.
If you don't realize that it's compromised, you're now using a compromised system regardless of the bootloader. If you do realize it's compromised then you do a clean reinstall of the OS and designate your bootloader as the trusted one again instead of whatever the compromised OS installed.
What does the bootloader really get them that root didn't already?
> The firmware validating the signatures only has public keys.
Having the keys installed from the factory still seems like the thing causing the problem:
If it only trusts e.g. Microsoft's public key, they now get to decide if they want to sign something you might want to use. If they don't, secure boot prevents it from working, which causes problems for you if you want it to work.
Which then puts them under pressure to sign all kinds of things because people want their firmware updaters etc. to work, and then you get compromised by some code they signed which wasn't even relevant to you.
Whereas what you want is some way of designating what can run on your machine, regardless of what someone else would like to run on theirs. But then that's a machine-specific determination rather than something somebody should be deciding globally for everyone.
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#119Earlier quoted context omitted.
Not so, the reference implementation is open source and incorporated into Coreboot, for a long time now.
The reference implementation is not the same as knowing which code runs on "your" hardware and having all keys from "your" hardware. If you are protected by a steel door but you don't have the keys, you are not safe, you are imprisoned.
This seems like a ridiculous argument. There is a fully source open source secure boot implementation, that if you have concerns about it you can fully audit, just as you can fully audit your current setup if you wanted to - but almost certainly have not.
Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
#120Earlier quoted context omitted.
The reference implementation is not the same as knowing which code runs on "your" hardware and having all keys from "your" hardware. If you are protected by a steel door but you don't have the keys, you are not safe, you are imprisoned.
This seems like a ridiculous argument. There is a fully source open source secure boot implementation, that if you have concerns about it you can fully audit, just as you can fully audit your current setup if you wanted to - but almost certainly have not.
So you are suggesting me to audit an implementation which I do not necessarily run and there's no way to know if I do. What's the point? How will it help?
The code running on my hardware is open, so anybody from the community can audit it and I have a possibility to verify that this is what I run at least by reflashing it. And I did reflash it. This approach is getting more reliable with more software becoming reproducible.