Usefulness of UEFI

[PeterX]

There is already a lot of tampering in that area by Windows installations. Even if you erase or replace the Windows boot .efi file, the firmware might still want to boot Windows, some way or another, for instance by restoring it from some backup or booting from somewhere else.

I sincerely hope this is not true! That would be a nightmare!

Greetings
Peter

[Gigasoft]

that arbitrary unchecked code

Then your firmware doesn't behave according to the UEFI specification. Your computer is broken - go return it. When Secure Boot is turned on, the firmware shall not load a driver from an option ROM or from the disk that is not signed with the appropriate key.

[rdos]

There is already a lot of tampering in that area by Windows installations. Even if you erase or replace the Windows boot .efi file, the firmware might still want to boot Windows, some way or another, for instance by restoring it from some backup or booting from somewhere else.

I sincerely hope this is not true! That would be a nightmare!

Greetings
Peter

Well, one of my laptops (actually the same one that didn't like it when ACPI annonced an older Windows version) had other tricks too. For instance, when I installed an multiboot efi-loader over the Windows loader, Windows was still loaded. Actually, it didn't stop misbehaving until I repartitioned the disc thus erasing everything and recreated the EFI system partition. At that point, it no longer could insist on loading Windows, and so worked like it should have from the start.

So, if you have a laptop with Windows preinstalled that you want to run your own stuff on, make sure you recreate the disc partitions to make sure Windows is completly gone.

[PeterX]

Well, one of my laptops (actually the same one that didn't like it when ACPI annonced an older Windows version) had other tricks too. For instance, when I installed an multiboot efi-loader over the Windows loader, Windows was still loaded. Actually, it didn't stop misbehaving until I repartitioned the disc thus erasing everything and recreated the EFI system partition. At that point, it no longer could insist on loading Windows, and so worked like it should have from the start.

So, if you have a laptop with Windows preinstalled that you want to run your own stuff on, make sure you recreate the disc partitions to make sure Windows is completly gone.

Wow, that's terrible. But good to know that!

Greetings
Peter

[bzt]

You forget that many motherboards are manufactured in China, and so might contain backdoors

While that's true, spreading a board with malicious code put there by the manufacturer gets into light in no time. That's why the U.S. is banning Huawei. You can choose not to buy Chinese boards, problem solved. On the other hand you cannot avoid a malicious attacker to alter your ESP if they really really want to. And they don't have to be the manufacturer for that, anyone can do that with physical access to the machine (evil maid attack) or remotely using another exploit in the OS.

Then your firmware doesn't behave according to the UEFI specification. Your computer is broken - go return it. When Secure Boot is turned on, the firmware shall not load a driver from an option ROM or from the disk that is not signed with the appropriate key.

This will work without violating the UEFI spec and Secure Boot turned on. You see, the problem here is, that you (as the machine's owner) have absolutely no control over what appropriate key is. If Microsoft's privkey gets out (as it has), if the attacker get their hands on the FBI's golden key (as they have), or one of the manufacturer's employee steals the privkey (as it happened with the Sony PSP and XBox One's private keys), you're screwed. Any rootkit can be installed even though the user thinks Secure Boot is on, so it must be safe, right? Well, in reality it isn't.

And we haven't spoken about that little security fiasco, where Windows' BOOTMGR.EFI (which is signed by MS, so works with Secure Boot no probs) will turn off Secure Boot if the loaded policy file says so... (the policy file isn't signed, and can be easily altered, just a plain simple file on the ESP). Even though this has been fixed, you can replace it with an exploitable (but signed) BOOTMGR.EFI.

Or when you could do the same with Grub, because it's configuration file must look like a programming language which it can't properly validate nor control. It was possible to load any .efi file from a grub.cfg, and even though they've fixed the issue, you can easily replace it with the old exploitable (but signed) GRUB.EFI.

You can do all of that with 100% complying with the UEFI spec and Secure Boot turned on. That's because UEFI is a failure by design.

Cheers,
bzt

[kzinti]

but my kernel can make it impossible for the rootkit to work once the kernel gains control. I do everything I can to stop UEFI malware from infecting my OS (there's no guarantee I can block all the attack vectors, but sure as hell I can make a malware's job pretty damn hard). I don't even care if my OS crashes when the UEFI is infected, that's much much better than letting the malware to run.

This is interesting... What kind of techniques do you use to block rootkits? What do you do about other attack vectors?

[zaval]

"if the private key gets stolen, then you are screwed up ... that's because UEFI is a failure by design".
so, if you get punched in your face by one's fist and your nose gets smashed, you are a "failure by design", right, bzt?

man, what a p00p you and your fanboy has turned this forum into. every topic is bzt announcing his next ultramoronic megaproject or emitting his paranoid nonsense or giving afwully bad advices for newcomers, if not fighting with those, who had the unluck to go argue with him.

for the OP, if you instead of producing BS threads, managed to read the 1 and 2 chapters of the spec, which are "Introduction" and "Overview" respectively, and they are short and clear, you wouldn't have had this absolute misunderstanding of the subejct, and thus wouldn't have created another garbage thread, whose only role is being a scene for bzt to sing his repulsive songs, letting him vomit here his sick hatred.

[dengeltheyounger]

"if the private key gets stolen, then you are screwed up ... that's because UEFI is a failure by design".
so, if you get punched in your face by one's fist and your nose gets smashed, you are a "failure by design", right, bzt?

man, what a p00p you and your fanboy has turned this forum into. every topic is bzt announcing his next ultramoronic megaproject or emitting his paranoid nonsense or giving afwully bad advices for newcomers, if not fighting with those, who had the unluck to go argue with him.

for the OP, if you instead of producing BS threads, managed to read the 1 and 2 chapters of the spec, which are "Introduction" and "Overview" respectively, and they are short and clear, you wouldn't have had this absolute misunderstanding of the subejct, and thus wouldn't have created another garbage thread, whose only role is being a scene for bzt to sing his repulsive songs, letting him vomit here his sick hatred.

I have not been here long, and so I have no idea what you are saying about bzt. He has appeared to be a little bit snarky in a couple of comments in this thread, but overall your comment right here is far more uncharitable than what I have seen from bzt in this thread.

The greatest concern I have about UEFI, various PC components, and firmware in general is the opaqueness. Even if UEFI is perfectly okay, security through obscurity generally does not seem to be the best policy. It seems that it protects the company developing the hardware and firmware, but fails to protect the user. Regardless, any firmware or hardware should be most secure when the community overall is able to examine the code, improve it, and also point out areas where users could harden themselves against inherent weaknesses. When it comes to firmware, we don't really seem to do this, and there seems to be a major source of insecurity. Overall, my own concern about UEFI is the opaqueness.

That being said, I'm not a security engineer. I'm very new to this forums, and I'm also very new to operating systems in general. I would be happy to receive any correction about what I have said (either if I'm wrong about the opaqueness of UEFI, or if my post is too far off topic).

[bzt]

The greatest concern I have about UEFI, various PC components, and firmware in general is the opaqueness.

Well said.

Even if UEFI is perfectly okay, security through obscurity generally does not seem to be the best policy.

First thing they teach you in every security and ethical hacker course is, that security by obscurity never works. Never.

It seems that it protects the company developing the hardware and firmware, but fails to protect the user.

Exactly. "Secure" Boot is just about locking in computers to Windows only, nothing else. (In theory you could install any company's keys, but in reality machines only shipped with MS keys, even big commertial Linux distributors like ReadHat or Oracle couldn't arrange to get their keys installed by default).

Regardless, any firmware or hardware should be most secure when the community overall is able to examine the code, improve it, and also point out areas where users could harden themselves against inherent weaknesses.

This doesn't just stand for firmware and hardware, but it is true in general.

When it comes to firmware, we don't really seem to do this, and there seems to be a major source of insecurity.

You could try coreboot, but sadly the number of supported motherboards is limited, and ever since FB, G and other IT giants started to contribute to it, it's full of bugs and regressions. Thankfully it has great automated testing infrastructure like Asan and other checks, and the community is eager to fix those bugs in reasonable time. All-in-all I would choose coreboot over UEFI every time I can.

Cheers,
bzt

[bzt]

This is interesting... What kind of techniques do you use to block rootkits? What do you do about other attack vectors?

Not mapping UEFI run-time for one. A malicious code can't do anything if it's not mapped in and never executed. Using properly written, sandboxed interpreters for bytecode and only when it's absolutely necessary. Only running a very very minimal part of the OS with supervisor privileges, push everything into isolated address spaces. Never share stack between user-space and kernel-space. Mapping everything I can read-only and no-execute, even if that means more complex syscalls. Implementing the dynamic loader in kernel, so that user space code can't load data that's later executed, only kernel allowed to do that. Etc. There are no clear cut instruction for security, you must use your several decade of experience and do your best. It's always going to be a who-is-more-through fight between security engineers and attackers. But if you deliberately install backdoors in your software, then attackers win for sure.

Cheers,
bzt

[kzinti]

So how does your bytecode interpreter determines if accessing an address or I/O port is safe and allowed?

[bzt]

So how does your bytecode interpreter determines if accessing an address or I/O port is safe and allowed?

First of all, read this, then study other sources how they do it, like this or read articles like this for example or even studying ASAN or selinux concepts on capabilities could be useful to you as you're not even familiar with the basics.
Otherwise try to search for "secure coding" and "sandbox environment", you will be surprised. Or just start here

Cheers,
bzt

[kzinti]

as you're not even familiar with the basics.

I know a lot about sandboxing. It's your credentials that I am trying to assess. You can't apply the usual sandboxing techniques to ACPI bytecode, nor are capabilities going to help with anything here. This is why I am asking you since you are the "security expert". So far you are not coming across as someone who knows much about anything security-related.

You claim to be able to protect your OS from rootkits and when asked how you deflect, ignore, deflect and then condescendingly point me to articles about JVM sandboxing which are not going to help with the current scenario.

You claim that mapping the UEFI runtime services in your OS is a security risk, yet you don't even understand how the API to do so works. Someone who is a "security expert" would have thoroughly investigated how this API works (including built some prototypes) before making any claims about it.

How do you prevent your ACPI interpreter from accessing unauthorized/unsafe addresses and I/O port? (i.e. how do you determine that an address or I/O port is allowed to be used by ACPI). How do you detect and/or mitigate bytecode that has been tempered with? You have claimed to do both. How do you do it?

I'd ask you to stop deflecting and changing the subject, but I know it's pointless and that I will never receive any satisfactory answer from you as you are just lying over and over about things you don't know. When feeling cornered (or otherwise), you attack by insulting people like you just did by pointing me to https://wiki.osdev.org/Required_Knowledge.

I don't agree with Zaval's use of language. But I do understand the feeling and agree with the substance of what he says.

[Ethin]

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. Therefore, I kindly ask you to do something that any security expert would happily do:
1. Please provide us with your security credentials/certifications as well as any verification codes so that we may verify them online (e.g.: through CompTIA). (Normally, I would not ask for this information, as it sometimes is of little value, however you have made a lot of accusations and claims about security and have yet to provide any actual evidence, which is why I have asked for this information.)
2. Please provide us with PoCs and/or evidence that demonstrate:
- how mapping UEFI runtime services is a security risk;
- how your kernel is capable of all your claims; and
- 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.
And no, common sense is not a factor in any of these; I explicitly want you to provide me with PoCs that will work in real-world scenarios and not theoretical ones if at all possible.
Furthermore, I find it really strange how you have this ridiculously over-paranoid distrust about all things technology. You claim that we shouldn't trust UEFI, and then you go on to claim how BIOS is supposedly more secure because it can't load UEFI runtime code. I explicitly refute this by noting that legacy BIOS is far less secure because it in fact can and does load *any* binary on disk, and does not perform any kind of integrity verification or other kind of check to prove that the binary its loading is what it claims it is. Secure boot may be used as a vendor lock-in mechanism, however that was not its purpose; security experts (who are far more knowledgeable in this subject than you or I) introduced the feature to explicitly prevent unsigned binaries from being loaded to eliminate, as best as is possible, the possibility of malicious code being introduced into the boot process. Once a (signed) binary is loaded, control is passed onto it. The vulnerabilities that that loaded binary may or may not contain is not evidence conducive to proving that secure boot is, in fact, not secure. As an example, the "boot hole" vulnerability in GRUB was not a vulnerability in secure boot, but in GRUB. The boot process was perfectly secure, because once GRUB received control from the firmware, it was GRUB's job to continue the integrity checks beyond that which the firmware is capable of. A vulnerability in GRUB does in no way mean that the firmware's side of the secure boot protocol was vulnerable.
I, for one, find your paranoia rather annoying. If you cannot trust the firmware, then you cannot trust anything and you might as well not code anything at all. The firmware is your interface to the hardware of the machine. Its present not only in the form of BIOS/UEFI but in the form of processor microcode, ACPI, SMM code, ROMs in PCIe configuration space, and so on. There is a point where you are required to compromise about trustworthyness, and the firmware is that point. You must trust, to the best of your ability, that the firmware is doing what its supposed to. You must trust that the ACPI code is properly written. You must trust that the SMM handler isn't spying on you whenever an SMI is triggered. And you must trust the hardware. If you can't trust one of those, then you really should ask yourself why your here. Security is wonderful and fine, but it becomes a problem -- yes, a problem, what a surprise? -- when overdone.
But hey, since your the "security expert", please do kindly provide me PoCs that work in real-world scenarios that prove your claims. I'd also like to see your (professionally audited) kernel code as well -- it must be truly amazing if it can do what you claim, and it should be used in Windows and Linux to harden those OSes as well. Hell, if its as great as you claim, every OS should adopt it.

[rdos]

This is interesting... What kind of techniques do you use to block rootkits? What do you do about other attack vectors?

Not mapping UEFI run-time for one. A malicious code can't do anything if it's not mapped in and never executed. Using properly written, sandboxed interpreters for bytecode and only when it's absolutely necessary. Only running a very very minimal part of the OS with supervisor privileges, push everything into isolated address spaces. Never share stack between user-space and kernel-space. Mapping everything I can read-only and no-execute, even if that means more complex syscalls. Implementing the dynamic loader in kernel, so that user space code can't load data that's later executed, only kernel allowed to do that. Etc. There are no clear cut instruction for security, you must use your several decade of experience and do your best. It's always going to be a who-is-more-through fight between security engineers and attackers. But if you deliberately install backdoors in your software, then attackers win for sure.

Cheers,
bzt

I cannot see how this can do anything about SMM, firmware in PCIe boards, Intel's SoC, ACPI byte code or even manipulating the EFI system partition. After all, the EFI system partition is an ordinary FAT32 partition and has no security at all.

As for mapping the UEFI runtime, I cannot see the point. It's more or less useless.