Buffer overflow reported in UEFI EDK1 A pair of security researchers have found a buffer overflow vulnerability within the implementation of the unified extensible firmware interface (UEFI) within the EDK1 project used in firmware development. Bromium researcher Rafal Wojtczuk and MITRE Corp's Corey Kallenberg said the bug in the FSVariable.c source file was …
What do you expect from a boot system that's larger than the Linux Kernel, but has been developed over a short time span largely in obscurity?
Seriously UEFI is yet another example of an overly complex solution to a simple problem. It tries to solve the 0,1% of problems nobody has while ignoring the basic requirements.
"doesn't lead to any useful features."Secure Boot and faster POST.
Precisely, no useful features. BIOS post even on a slow machine with a lot of RAM didn't take that long (servers are a different matter, but not frequently rebooted) and Secure Boot is destined to become more of a headache than the problem it tries to solve.
>Please explain how Secure Boot is destined to become more of a headache than the problem it tries to solve.
If you just intend running Windows or Mac OS on a new computer - as you may well do - then you will be ok. But as time goes on people who need/want to use Linux, or don't want to buy new hardware when upgrading their operating system will be increasingly screwed.
"But as time goes on people who need/want to use Linux, or don't want to buy new hardware when upgrading their operating system will be increasingly screwed"
Several Linux distros work with Secure Boot.
Secure Boot can be disabled in BIOS in case you can't or won't use it.
Interesting (well, not really) how many downvotes I get for pointing out facts or just asking for clarification...
@Sandtitz, It would appear that you have forgotten about all the industrial machines that don't and never will run windows. Many of them have old operating systems as the base for their work specialist programs.
We have just replaced some motherboards on some industrial equipment and the biggest headache we had was finding replacement boards that would allow us to disable all the UEFI secure boot crap that interfered with not only the OS but some of the programs.
While you might think it is the best thing since sliced bread there are others of us that consider it nothing more than a so called solution looking for an apparent problem that microsoft caused themselves and a total waste of time in the real world where actual work is done.
We have just replaced some motherboards on some industrial equipment and the biggest headache we had was finding replacement boards that would allow us to disable all the UEFI secure boot crap that interfered with not only the OS but some of the programs.
Ivan,
please name those motherboards you tried and failed with.
Microsoft's Windows Hardware Certification Requirements says that "Disabling Secure Boot must not be possible on ARM systems" if the manufacturer wants to offer Windows on it.
That is true, but those Windows RT devices (never seen one) and WPhone products are not commodity hardware (as in generic x86 PC) and are no different from the bootlocked iPhones or Androids.
"That is true, but those Windows RT devices (never seen one) and WPhone products are not commodity hardware (as in generic x86 PC) and are no different from the bootlocked iPhones or Androids."
Because there are 'only' a few million of those devices, or because Apple also uses similar practices, doesn't make it OK for Secure Boot to be used to lock users into a particular operating system.
Please explain how Secure Boot is destined to become more of a headache than the problem it tries to solve.
On paper, Secure Boot looks good. It has a number of flaws though.
Secure Boot requires that the boot loader be signed by a key known to the UEFI firmware before being permitted to boot. This therefore implies that the device must be pre-loaded with the public keys of known publishers before it ships to the customer.
Thankfully on x86, the requirement is that the user must be able to add their own keys. This is not a trivial process however and differs between UEFI implementations. So immediately, anyone who has a desire or need to run an OS other than one of the select few, has a few more hurdles to jump over.
Ever tried getting into the UEFI setup on a modern x86 machine? You need lightning quick reflexes, and an educated guess as to what button to hit! Been there, done that on a few machines.
Moreover, this assumes that the private key for the publisher you use does not get compromised. The moment that happens, sure, they can revoke that key but then:
- the old kit will still recognise and accept that compromised key, until such time their firmware gets updated (How often do people here update their boot firmware I wonder? How many devices will never have updates provided?)
- someone's legitimately paid-for OS suddenly stops working on newer hardware, that WILL get people upset.
Others have pointed out that there is a lot of code in the UEFI kernel. Matthew Garett claimed as much as 100MB of source code in TianoCore which is the reference UEFI implementation. If you've got the time, have a look at the whole video (I watched the presentation in person).
As a matter of interest:
RC=0 stuartl@vk4msl-mb /tmp $ tar -xJf /home/portage/distfiles/linux-3.14.tar.xzRC=0 stuartl@vk4msl-mb /tmp $ cd linux-3.14/
RC=0 stuartl@vk4msl-mb /tmp/linux-3.14 $ find . -type f -a \! \( -name \*.h -o -name \*.c \) -delete
RC=0 stuartl@vk4msl-mb /tmp/linux-3.14 $ du -hs .
538M .
So just under one fifth of the entire Linux kernel. UEFI runs on i386, AMD64 and ARM to my knowledge. Linux runs on that and some, including obscure machines most have never heard of.
Two facts of life:
- people write code
- people make mistakes
Therefore, there will be lots of bugs in that UEFI code, including the stuff that implements Secure Boot. There is a lot of complexity to debug which will seem foreign to the old-hands used to the ye olde BIOS when things go wrong.
With the rush to get things to market, you can bet your bottom dollar that manufacturers won't be testing their code to ensure it's safe from malware (the intended target for Secure Boot), but you can guarantee the blackhats will! I therefore believe that while there were some noble ideas in Secure Boot, it in all probably will not achieve what it ultimately set out to achieve, and will instead cause grief with all the additional things that can go wrong.
"Thankfully on x86, the requirement is that the user must be able to add their own keys. This is not a trivial process however and differs between UEFI implementations. So immediately, anyone who has a desire or need to run an OS other than one of the select few, has a few more hurdles to jump over."
You are correct. Then again, security is not easy and if you desire to use any type of trusted boot you'll be installing certificates or TPM-like hardware. If you want to boot into an OS that isn't covered by the preloaded keys you'll just have to disable the Secure Boot thingy. No OS that I know of requires Secure Boot and probably never will on x86.
"Ever tried getting into the UEFI setup on a modern x86 machine? You need lightning quick reflexes, and an educated guess as to what button to hit! Been there, done that on a few machines."
The "educated guess on the correct button" for entering setup is just as problematic with or without UEFI. Cold boots help if you're too slow to react. ;-)
"Others have pointed out that there is a lot of code in the UEFI kernel."
I'm not disagreeing with that.
The whole debacle with UEFI reminds me a lot of the introduction of ACPI back in the 90s. Linus et al. were cursing it since it was much more complex code and thus prone for bad implementations (which was true) but it brought noticeably better power savings than APM from the get-go and my problems with ACPI have been with the computers before WinXP era.
"With the rush to get things to market, you can bet your bottom dollar that manufacturers won't be testing their code to ensure it's safe from malware (the intended target for Secure Boot), but you can guarantee the blackhats will!
How do you propose they could ensure safety from malware? No-one does that and I still haven't found a vendor that didn't have bugs in their security software.
"I therefore believe that while there were some noble ideas in Secure Boot, it in all probably will not achieve what it ultimately set out to achieve"
So far I haven't seen reports of bypassing it. I'm sure there are bad implementations though.
"and will instead cause grief with all the additional things that can go wrong."
Look, there's all sorts of stuff that will cause grief to some parties, be it any new technology or the lack of it. OpenSSL has fucked up royally and caused lot of grief yet I'm still using their tech.
So far the Secure Boot problems i've seen and heard of have fallen into one category: how do I turn it off?
If you have ever developed or contributed to any open source operating system, you would've not made this comment. I say this, as after Secure Boot started getting slipped into almost every mobo out there, the bug reports on Free/Net/OpenBSD, and Linux started pouring in. If we could quantify the amount of developer hours wasted on trying to triage bugs that were ultimately caused by Secure Boot, I feel we might have a chance to have this "feature" stripped out going forward. Unfortunately, there's a *LOT* of hardware manufacturers that DO NOT allow Secure Boot to be disabled. Enjoy your new-shiny!
We never needed a kitchen sink. We really didn't even need faster boot, and while no one is complaining about that, we certainly didn't need the whole kitchen sink of UEFI brought in just to get faster boot.
What problems did the BIOS have that we DID need solve? How about a standard interface for one thing - make it so you ALWAYS use the same key to access the settings, and you do so by HOLDING DOWN that key rather than trying to press it during the small window (ever shrinking as boot gets faster) when that keypress is accept?
How about standard menus, for all the functions that all systems need. All the standard and common optional items are put into the same place so you don't need to go looking around or figure out what goofy name this OEM or motherboard maker decided to call it? Specialty stuff can go into an 'OEM' menu where they can deal with oddball items that aren't common on a PC/laptop but would be used on other types of devices like say an ATM.
I could go on, but these are the problems the BIOS had. Lack of speed as I said could be done without all the crap UEFI layered on. Secure boot should have been done with a more modular approach that left the security sensitive part of the code small enough to formally verify. Then this type of bug wouldn't happen.
Oh, and being open in the development process rather than working mostly in secret would have helped too. Not that "many eyes" guarantees a lack of bugs, but it makes it makes it a lot harder for a basic mistake like a buffer overflow to ship in tens or hundreds of millions of devices.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
