Usefulness of UEFI

[bzt]

bzt, I find it quite ironic that your pointing out all of these supposed "security risks" when you have yet to prove any of it.

I don't have to prove anything, others have already done that. I was just referring to their works, I've cited the CVE numbers too if you don't believe me (see below).

- how any of the vulnerabilities that you've pointed out (in, say, Grub or the MS bootloader) are vulnerabilities in the secure boot mechanism itself.

Here are some links to read for you (by no means a complete list, many other vulnerabilities exists):

FBI golden key leak, CVE-2016-3287 (those who found the bug insisted that MS' patch MS16-094 did not solve the problem, and they were right: CVE-2016-3320), see also CVE-2020-0689 and MS security update 2021-01-12. It is still ongoing and hasn't been fixed properly (experts say you cannot fix it because of design flaws in UEFI, and they are right. It is not possible to list all malicious code's hash in the DBX, there will always be a new one)
Pay attention to the following sentence, said by MS itself:

Code: Select all

A security feature bypass vulnerability exists in secure boot.

GRUB2's bug also dubbed boothole, CVE-2020-10713 and CVE-2020-14308 and CVE-2020-15705 (there's more).

WikiLeaks CIA tools here replace driver with run-time, and ExitBootServices with any of the functions in the run-time services table. The mechanism will be the same. Has example code too.

Here's a not comprehensive list of some of the vulnerabilities from Microsoft (6814 in total, but 2020 second half and 2021 not included), search for "secure boot" and "efi".

Cheers,
bzt

[rdos]

Here are some links to read for you (by no means a complete list, many other vulnerabilities exists):

FBI golden key leak, CVE-2016-3287 (those who found the bug insisted that MS' patch MS16-094 did not solve the problem, and they were right: CVE-2016-3320), see also CVE-2020-0689 and MS security update 2021-01-12. It is still ongoing and hasn't been fixed properly (experts say you cannot fix it because of design flaws in UEFI, and they are right. It is not possible to list all malicious code's hash in the DBX, there will always be a new one)
Pay attention to the following sentence, said by MS itself:

Code: Select all

A security feature bypass vulnerability exists in secure boot.

GRUB2's bug also dubbed boothole, CVE-2020-10713 and CVE-2020-14308 and CVE-2020-15705 (there's more).

WikiLeaks CIA tools here replace driver with run-time, and ExitBootServices with any of the functions in the run-time services table. The mechanism will be the same. Has example code too.

Here's a not comprehensive list of some of the vulnerabilities from Microsoft (6814 in total, but 2020 second half and 2021 not included), search for "secure boot" and "efi".

Cheers,
bzt

Great, so now we have a way to disable secure boot on laptops that are locked-down with Windows?

[bzt]

Great, so now we have a way to disable secure boot on laptops that are locked-down with Windows?

Essentially yes It's not only the malicious rootkits that can take advantage of this, we hobby OS developers can benefit from it too. (Actually that's the biggest problem with backdoors in general: not only those who've created it can use it, but once it's leaked, anybody can use it, for good and bad alike)

Cheers,
bzt

[rdos]

I don't understand how grub2 can run as a secure boot method at all. It is the grub.cfg file that dictates what will be loaded, and since it cannot be signed, it should be possible to load just any operating system. Unless, of course, the modules that are loaded needs to be signed too.

How do you actually get your efi boot-loader signed? I have an efi loader that will look for OS images on the EFI system partition, and then will load a binary stub and hand it a pointer to the OS image. The OS image apparently cannot be signed given that it will change based on the actual configuration, however, it has internal check-sums which means you cannot change things in the drivers without knowing that. OTOH, I provide a tool to generate OS images from a configuration file. Signing the stub-loader would be possible, but makes no sense since it's just an interface between EFI and the kernel embedded into the OS image.

OTOH, I could lock-down the system by not providing any tools to change the EFI system partition.

So, grub2 and my loader have the similarity that they have a basic configuration file that has dynamic content and thus cannot be signed. However, every OS has some dynamic content somewhere in the boot process, which might change with updates or driver changes. If this is early in the process (like the grub.cfg or my OS images) or further down in the process, really should matter a lot. It can still be tampered with, one way or another.

I think most of this "security" is just by making things overly complex.

Thinking further on this, I could embed a key into the stub loader, and use that key to decrypt the OS images, and then sign the stub loader. The OS images would then need to be encrypted with this key before being put on the EFI system partition. Wouldn't that be a secure method as long as the keys remained private? The problem is that the UEFI standard cannot enforce it in a good way. It would all be up to me to make sure it was hard to break, and would still be security based on complexity.

[Ethin]

bzt, there is actually things you have to prove. Very little of any of the CVEs you listed corresponded to the secure boot process at all. The majority of vulnerabilities you listed (CVE-2016-3287, CVE-2016-3320, boot hole, CVE-2020-10713, CVE-2020-14308, and CVE-2020-15705) are vulnerabilities in programs loaded by secure boot, not in secure boot itself. Notably, none of the vulnerabilities you listed exist if you (1) do not have Windows installed and therefore manage your own key databases and (2) use the latest version of Grub. The WikiLeaks hack only works if you load an UEFI driver, and UEFI drivers, also, need to be signed when secure boot is enabled. Pretty much all of the vulnerabilities that Microsoft lists are Windows-specific.
Now, these vulnerabilities are relevant, and call into question Microsoft's ability to audit their own code. But it does not actually prove that the UEFI side of secure boot is broken. Yes, it is not possible to list all possible hashes in the DBX, just as it is not possible to list all possible virus signatures in antivirus signature databases. The point of secure boot is not to list every possible malicious hash signature, but to list the ones we do know to prevent them from loading, just as the purpose of an antivirus signature database is to list all the malicious signatures we know to delete them when they are detected. We will undoubtedly miss many as new variants are created every day, but that is to be expected.
And you still haven't proved anything else I listed, either. Granted, you don't have to prove anything, as you said, but that only makes me take what you say with a (even larger) grain of salt.

[Gigasoft]

Not mapping UEFI run-time for one. A malicious code can't do anything if it's not mapped in and never executed.

Sigh... It was already executed before your code runs! If a hacker is able to circumvent secure boot, do you really expect them to rely on your OS calling UEFI runtime services in order to get control? No, they will of course take over the boot process immediately and make any changes they want to your kernel before it runs.

Those articles you linked to are about flaws in various operating systems and have nothing to do with UEFI itself. If someone is booting into your OS using Secure Boot, it will be signed with your key, not Microsoft's key or GRUB's key. Just as easily as the user added your key to the set of authorized keys, he can remove all other irrelevant keys.

And no, I don't believe for a second that you are a "security expert". An expert is "somebody who has a broad and deep competence in terms of knowledge, skill and experience through practice and education in a particular field." (source: Wikipedia), which you clearly don't.

[bzt]

Very little of any of the CVEs you listed corresponded to the secure boot process at all.

Interesting, all of them are specific to Secure Boot environment only.

vulnerabilities in programs loaded by secure boot, not in secure boot itself.

Quite the contrary, it demonstrates that even signed and verified programs can break from Secure Boot, which was my point. Secure Boot by design cannot work, only if all programs were mathematically proven to be bug free and correct. Which they are not.

Not mapping UEFI run-time for one. A malicious code can't do anything if it's not mapped in and never executed.

Sigh... It was already executed before your code runs!

Halt right there. I wrote that in response to "inject code into kernel".

Cheers,
bzt

[Ethin]

Very little of any of the CVEs you listed corresponded to the secure boot process at all.

Interesting, all of them are specific to Secure Boot environment only.

That's funny, because they pertain to the Windows and GRUB boot loaders and the Windows operating system, not to any specific UEFI firmware implementation. I believe you are intelligent enough to know that just because something is categorized under "secure boot" (or any other general categorization) does not make it actually about that subject; secure boot is just used as more of a tag. It does not actually mean that the vulnerability is a problem in the firmware. Are you saying that me assuming that you are intelligent enough to know this is incorrect?

vulnerabilities in programs loaded by secure boot, not in secure boot itself.

Quite the contrary, it demonstrates that even signed and verified programs can break from Secure Boot, which was my point. Secure Boot by design cannot work, only if all programs were mathematically proven to be bug free and correct. Which they are not.

I'm not really sure where you get this logic from. I really don't. By your logic, we shouldn't have TLS certificates because we can't prove that the implementations handling those certificates are bug-free, and therefore TLS doesn't work. By this logic, we should just not use any form of encryption, because no implementation of a cryptographic system is bug-free in implementation, and may not even be mathematically unbreakable. By this logic, I should erase all the antiviruses on my computer because they're not bug-free and can't protect me from all the evils in the world.
You seem to be under the false assumption that secure boot should be designed to protect you from every single malicious binary that has and will ever be created. As a software developer yourself, I'm surprised you would take such a stance, because I assume that your intelligent enough to know that such a stance is utopian in nature and will never happen. I have already explained the rationale of secure boot to you. Secure boot is like an antivirus: it protects you from code that we know to be malicious. It cannot, and does not claim to, protect you from everything. The firmware cannot possibly secure the entire boot sequence; to do such a thing would require the firmware to be the operating system as well, and though that's an interesting project that I might give a go at sometime, it would not actually be practical given that real computers make it deliberately difficult to flash firmware images (and for good reason). Secure boot is only designed to protect systems from malicious code before a *signed* binary is loaded. Once a signed binary is loaded and control has been passed to it, the firmware's job (and by extension, the job of secure boot) is done; it has done what it was intended to do. If the loaded binary wishes to continue the trend of secure boot, and to continue checking everything it loads to verify that a completely unmolested boot chain exists, then it may do so. But it is not obligated to do so. The vulnerabilities that you listed are *not* vulnerabilities in secure boot. They are vulnerabilities in the signed binaries that the firmware loaded. Just because a vulnerability exists in a signed loaded binary does not imply that the entire secure boot process is vulnerable or should not be used, or that it was mis-designed or improperly implemented; to conclude such a thing is illogical. To prove that a vulnerability exists in secure boot, you would need to trick the firmware to load an unsigned (or signed but not known) binary while secure boot is enabled. If you can do that, and prove that such a thing is possible, as well as providing IoCs and PoCs, then you will prove that the implementation of secure boot that your testing is vulnerable... But that will still not mean that secure boot itself is vulnerable. To indicate that secure boot itself is vulnerable you'll need to further extend those PoCs to a wide range of UEFI implementations. Only then, after extensive research and testing, can you say with any degree of confidence that secure boot is vulnerable. To claim that it then was improperly designed requires you to prove a lot more than just that; you need to indubitably prove that no way of implementing secure boot, as the specification demands, is correct. That is a much harder task.
To be honest I'm amazed anyone even buys your tripe on this forum at all. You are very obviously no security expert and have absolutely no idea what your talking about when it comes to secure boot, or even, perhaps, UEFI in general. You refer to vulnerabilities in loaded signed binaries and then claim that that is evidence to prove your claim that secure boot is useless and that it always will be useless and therefore should never be used in any domain or context. When proof is requested, you refuse to provide it and act as though "others" have already done it for you, when in fact they have not; instead, you provide references to code that would never be loaded in a system with secure boot enabled unless the operator of that system was stupid enough to trust that code to begin with, which is a different problem altogether. When confronted, you act as though you are superior to the rest of us and act all condescending, referring us to articles like the required knowledge article on the wiki (even if said article is irrelevant to the actual discussion), and you clearly don't care how demeaning that is. And in doing all of that, you've lost all the respect I initially had for you as a fellow OS developer. I'm quite positive I'm not the only one who's lost respect for you either.

[bzt]

something is categorized under "secure boot" (or any other general categorization) does not make it actually about that subject; secure boot is just used as more of a tag.

In theory could be, but how do you explain Microsoft's statement

A security feature bypass vulnerability exists in secure boot.

then? It is quite straightforward.

It does not actually mean that the vulnerability is a problem in the firmware.

No, the vulnerability problem in the firmware is that it allows loading drivers and run-time services from disk in the first place not just from Option ROMs that rootkits cannot modify easily. Plus it is a nonsense that a machine owner has no control over which keys can be or cannot be used to verify those code... These are design flaws, which cannot be fixed by patching the loader or Windows and filling up the DBX, no matter how hard MS tries.

By your logic, we shouldn't have TLS certificates because we can't prove that the implementations handling those certificates are bug-free, and therefore TLS doesn't work.

No, the correct analogy would be: TLS worth nothing if you can't control who's certificate is accepted. And the attack vector: if an attacker can freely and silently install trusted CAs without you knowing, then indeed, you should not trust TLS.

Look, I've warned you. I only promised that I'll try to explain, there's no guarantee that you'll understand. It's not your fault, security is misguided and miseducated in general (so that CIA, FBI, NSA and all the other three-letters can use backdoors. The reasons are obvious, but the principle is flawed in the first place, because anybody can use those backdoors, even the bad guys. It's like you keep your house's front door wide open with a note on it "Only policemen can enter". Do you seriously think that that note would stop a burglar? You can't blame me trying to close my door.)

Cheers,
bzt

[kzinti]

Plus it is a nonsense that a machine owner has no control over which keys can be or cannot be used to verify those code...

Just more lies or paranoia fueled FUD. The UEFI firmware on all 3 machines I have allow me to add, remove or change keys easily. I get to decide which keys can be used to load my binaries. I can generate my own keys and use them. Saying that a machine owner has no control over which keys are installed is completely false.

One can reasonably criticize the vendor lock-in aspects of the UEFI secure boot mechanism, but this doesn't make it a security risk or vulnerability. You keep bringing up things that have nothing to do with each others in your crusade against UEFI. You also keep implying that the BIOS is more secure than UEFI, which is complete non-sense. The BIOS has no security mechanism at all.

Look, I've warned you. I only promised that I'll try to explain, there's no guarantee that you'll understand. It's not your fault, security is misguided and miseducated in general (so that CIA, FBI, NSA and all the other three-letters

I don't know if I should laugh or cry.

[rdos]

Just more lies or paranoia fueled FUD. The UEFI firmware on all 3 machines I have allow me to add, remove or change keys easily. I get to decide which keys can be used to load my binaries. I can generate my own keys and use them. Saying that a machine owner has no control over which keys are installed is completely false.

Not completely. I have several PCs where you cannot change keys, cannot turn off secure booting of Windows and where you don't have the control of secure booting like you want to as a user.

[kzinti]

Not completely. I have several PCs where you cannot change keys, cannot turn off secure booting of Windows and where you don't have the control of secure booting like you want to as a user.

Sure. That's not an UEFI design problem. That's a vendor lock-in problem. UEFI doesn't mandate this behaviour in any way. If your implementation doesn't allow it, bring it up with the manufacturer / firmware provider. Do your research and do not buy any computer where you are locked to Windows (which mostly is the low-end laptops and machines, you don't usually get this vendor lock-in on higher-end machines).

You are perfectly right to complain about it. I do see this as a big problem. But it has nothing to do with UEFI. The same could/would have happened with any other non-UEFI firmware that verifies binary signatures.

[Ethin]

something is categorized under "secure boot" (or any other general categorization) does not make it actually about that subject; secure boot is just used as more of a tag.

In theory could be, but how do you explain Microsoft's statement

A security feature bypass vulnerability exists in secure boot.

then? It is quite straightforward.

As has been explained to you previously, this is a flaw in the boot loader of windows, not the firmware.

It does not actually mean that the vulnerability is a problem in the firmware.

No, the vulnerability problem in the firmware is that it allows loading drivers and run-time services from disk in the first place not just from Option ROMs that rootkits cannot modify easily. Plus it is a nonsense that a machine owner has no control over which keys can be or cannot be used to verify those code... These are design flaws, which cannot be fixed by patching the loader or Windows and filling up the DBX, no matter how hard MS tries.

Oh, this argument cracked me up. Your complaining now because UEFI allows you to load binaries on disk... Oh, wait, the BIOS let you do that too! And the firmware of every other computer lets you load code from various sources that aren't internal ROMs too! Wow! What a huge security flaw! (Oh, wait... UEFI secure boot requires them to be signed, and any unsigned binary won't load, and any hash in the DBX also won't be loaded. So at least that's something.)

By your logic, we shouldn't have TLS certificates because we can't prove that the implementations handling those certificates are bug-free, and therefore TLS doesn't work.

No, the correct analogy would be: TLS worth nothing if you can't control who's certificate is accepted. And the attack vector: if an attacker can freely and silently install trusted CAs without you knowing, then indeed, you should not trust TLS.

I'm sorry, but no. This is not the "correct" argument at all. Please go re-read my post.

Look, I've warned you. I only promised that I'll try to explain, there's no guarantee that you'll understand. It's not your fault, security is misguided and miseducated in general (so that CIA, FBI, NSA and all the other three-letters can use backdoors. The reasons are obvious, but the principle is flawed in the first place, because anybody can use those backdoors, even the bad guys. It's like you keep your house's front door wide open with a note on it "Only policemen can enter". Do you seriously think that that note would stop a burglar? You can't blame me trying to close my door.)

Cheers,
bzt

So, in other words, your saying that your the god of computer security and that we should listen to you, but not to other security experts who tell us the opposite. "I only promised that I'll try to explain, there's no guarantee that you'll understand." This has to be one of the most arrogant statements I've read on this thread. You haven't explained a thing. If you had, people like myself wouldn't be showing you just how incorrect you are. As someone who has studied cryptography and UEFI extensively, I think I'm more qualified to discuss UEFI-based topics than you are. I have no security certifications but I'm not so bold as to act like I know everything about computer security and that everyone else is wrong. I have explained why your wrong in great detail. I have logically deconstructed each argument you try to use -- which really wasn't hard since none of your arguments make much sense and are only your sick way of distorting the truth of UEFI and what it's trying to do because you (somehow) magically think you can do better. The author of this topic created it to ask questions about UEFI and you converted it into this stomping ground so you could throw stones at UEFI because you've got some twisted nonsensical vendetta against it for some reason I'm pretty sure only you know. Instead of presenting the facts as-is, you deliberately and knowingly misinterpreted them and twisted them to fit your own narrative, and then, to further try to cement your argument, you included completely unrelated issues to try and make your point for you. Then, when people called you out on it, and requested proof, you deflected and complained about how we supposedly were failing to understand your point. Then, to add insult to injury, you insulted our intelligence, pointing us to articles you knew were demeaning and treating us like idiots. When I called you out on that, you then went on to act as though you were oh-so superior to the rest of us. To be honest, I'm amazed that no one has banned you for this kind of attitude yet, since I'd think that this kind of treatment from you, to anyone, is against the rules on here. This has turned from a discussion about the uses of UEFI and its runtime services to a place for you to scream your tripe to the rest of the world, as you seem to do with any other topic when UEFI is brought up.
Anyway, bzt, I'm tired of fighting with you. Take your twisted UEFI war elsewhere, please. Its not welcome nor wanted here.
@OP: I apologize that your topic was transformed into this. It seems like bzt just cannot resist going on an immature and childish rampage whenever UEFI and secure boot are mentioned in a topic, nor can they resist spreading FUD all over the place.

[Ethin]

@rdos: I think MS surface tablets do that (I know they used to at any rate). But the UEFI spec doesn't mandate user interface requirements anywhere, only that the secure boot databases shall be read-only by runtime services and system software, if memory serves. So that's not a design flaw of UEFI.

[rdos]

@rdos: I think MS surface tablets do that (I know they used to at any rate). But the UEFI spec doesn't mandate user interface requirements anywhere, only that the secure boot databases shall be read-only by runtime services and system software, if memory serves. So that's not a design flaw of UEFI.

Some laptops too, but it seems to have gotten better. I suppose all the criticism that MS got for this has made things a bit better.