7 ms·

PixieFail: Nine Vulnerabilities UEFI Implementations

152 points by weinzierl 3y ago

devaiops9001 3y ago
It's all so tiresome. Just write these parts in Rust already.
- RedShift1 3y ago
  Just don't make something so complicated just to boot an OS. The damn thing is an operating system on its own now.
  - p_l 3y ago
    It's arguably less complicated than late stage BIOSes were, and I'm not including UEFI Class 1 systems (what many systems people thought still had BIOS actually were)
  - weinzierl 3y ago
    I used to think like that but I changed my mind. I don't say UEFI is no over complicated, over engineered mess but I worked on embedded systems for a while and I'd say it's no sunshine there either. Booting a modern OS on modern hardware involves a lot of essential complexity you cannot get away from.
    - temac 3y ago
      The design of UEFI also involves tons of non-essential complexity.
      - weinzierl 3y ago
        Sure, but it is easy to keep essentially simple things simple; accidental complexity is unforgivable in this case. Systems that are inherently complex tend to naturally accrue accidental complexity. It's understandably hard to keep these systems lean. My point is that modern boot systems in general fall into the second category, contrary to other comments that imply the first.
  - Avamander 3y ago
    It just is that complicated to bring up all the pieces of hardware in a timely manner and with the right configuration. Not to mention if you want to let user configure things. Just look at say DRAM init: https://www.systemverilog.io/design/ddr4-initialization-and-calibration/ https://www.systemverilog.io/design/ddr4-initialization-and-... Of course you're gonna give that hard task to a memory controller, but then you have to initialise that. This goes on for all the subsystems, with complex interactions and features, all of which need handling. It's not a single microcontroller you're powering on, even if it were, those too require a bunch of initialisation code to function properly.
    - temac 3y ago
      DRAM init as little to do with UEFI or BIOS and Intel probably ships x86 components for more exotic or even allow custom bootloaders. At least at a time they did. I don't know the current situation but when I played with all of that, I saw one of their "Memory Reference Code" in particular the parts in charge of calibration of the memory controller timing, and that was a quite short piece of x86 assembly completely independent from the UEFI architecture insanities. Well because it was written in assembly it had an obvious bug, but that's another story.
  - jeroenhd 3y ago
    I disagree. UEFI makes my life, as an end user, so much easier. The amount of times I've needed to buy a different flash drive because the BIOS of a particular motherboard didn't like the way my existing flash drives smelled has gone down to 0. The thing even supports filesystems _not_ formatted by a tool written for Windows 95 that arranges the FAT partition in _just_ the right way to get it recognised. Previously, we had motherboards do the same stuff, except now they called into ROM memory on the network card, and ran a bunch of non-standard, proprietary code to render the fancy graphics and do online updating. I don't believe for a second that things were easier before UEFI standardised it all, they were just hidden from plain view better.
    - p_l 3y ago
      It helps that unlike with BIOS, the modern tooling doesn't have huge amounts of "we never read the spec but it booted on my machine" that was prevalent even with grub2. TL;DR a BIOS doesn't have to boot a drive if there's no primary partition marked "active", no matter whether your boot code uses that or not.
- crotchfire 3y ago
  Even better, dump that UEFI crap. Not even Rust can fix stupid. Just directboot a static kernel and kexec() the real kernel -- like petitboot has been doing since forever: https://github.com/open-power/petitboot/blob/master/README.md https://github.com/open-power/petitboot/blob/master/README.m... Unless you like writing everything (display drivers, disk drivers, filesystem drivers, network stacks...) twice. Which is where these bugs come from...
  - weinzierl 3y ago
    I think Oxide's computers don't use UEFI, but I don't know what they replaced it with. Since they are a Rust shop, maybe something written in Rust, but if not it would also be interesting to know and to know the reasons why.
    - delusional 3y ago
      They have a custom bootloader https://github.com/oxidecomputer/phbl https://github.com/oxidecomputer/phbl that runs without AGESA or any of the normal stack of stuff. From their podcast it sounds like it was quite a bit of work to get it working.
      - ciupicri 3y ago
        Yeah, if I remember correctly even AMD was amazed of what they did.
      - pbronez 3y ago
        Oxide co-founder Jessie Frazelle published an ACM Queue article about the security advantages of open source firmware in 2019: https://queue.acm.org/detail.cfm?id=3349301 https://queue.acm.org/detail.cfm?id=3349301
    - p_l 3y ago
      It works for them because they own the complete hardware stack, and boot only their hypervisor which is also something they control. TL;DR you can make it simple if you close the platform (this is not the same as open source Vs closed source) - open platforms end up developing complex interfaces so thatthey are actually open to end owners.
- mkopec 3y ago
  Rust won't magically fix every vulnerability and someone would have to pay a team of engineers to rewrite everything.
  - jeroenhd 3y ago
    > someone would have to pay a team of engineers to rewrite everything A partial effort has already been made a while back: https://github.com/tianocore/edk2-staging/tree/edkii-rust https://github.com/tianocore/edk2-staging/tree/edkii-rust However, this uses uefi-rs, which is incompatible with TianoCore's BSD+Patent licensing, and therefore cannot be used as reference material, as the wiki page states: https://github.com/tianocore/tianocore.github.io/wiki/Tasks-Add-Rust-Support-to-EDK-II https://github.com/tianocore/tianocore.github.io/wiki/Tasks-... More recent efforts have also been mentioned in the mailing list: https://edk2.groups.io/g/devel/search?p=recentpostdate%2Fsticky%2C%2C%2C20%2C2%2C0%2C0&q=Rust https://edk2.groups.io/g/devel/search?p=recentpostdate%2Fsti... Rust also has a basic standard library implementation now: https://github.com/rust-lang/rust/pull/105861 https://github.com/rust-lang/rust/pull/105861
    - the_panopticon 3y ago
      Some of the challenges in adding Rust to EDKII are described in https://cfp.osfc.io/osfc2020/talk/SLFJTN/ https://cfp.osfc.io/osfc2020/talk/SLFJTN/. There is some more recent work in this space described in https://microsoft.github.io/mu/WhatAndWhy/rust/ https://microsoft.github.io/mu/WhatAndWhy/rust/, too.
- jeroenhd 3y ago
  I agree, but Rust would've still had several of these vulnerabilities. The integer underflow would've passed in release mode (though you could argue that anything running this low level should spare the extra CPU cycles for checked arithmetic), the infinite loops hanging the system, and the predictable TCP sequence numbers. I'm not sure about the weak pseudo-RNG, because I would expect an existing crate to get imported for that use case, but the same RNG could also be implemented just as badly in Rust. As for the buffer overflow vulnerabilities: I completely agree. These are the most dangerous vulnerabilities and I doubt they would've made it past the compiler had they been written in Rust.
filleokus 3y ago
The disclosure timeline section is worth a read of itself: > 2023-11-14 Quarkslab replied to the prior requests and commentary from various vendors as follows: Stated that the blog post about the issues would contain the technical report submitted to the disclosure coordination forum and a detailed timeline of the relevant events in the disclosure process. It would include proof-of-concept code to trigger vulnerabilities 1 to 7 but NOT exploit code. Reiterated that the purpose of reporting the vulnerabilities was to help vendors identify and fix them, not to debate about the editorial policies for Quarkslab research work.
- marcus0x62 3y ago
  Pretty typical. Dealing with vulnerability reporting and disclosure has always sucked for researchers, and from my (very) limited experience on the vendor side, it isn't much better there. I'm honestly surprised more of these researchers haven't gone back to the bugtraq/full disclosure model.
tonoto 3y ago
What more vulnerabilities hides in the proprietary UEFI? I have no interest whatsoever to install MS Windows, is there any motherboards out there for AMD64/X86_64 that comes without UEFI/BIOS?
- yencabulator 3y ago
  You might like these https://frame.work/blog/open-sourcing-our-firmware https://frame.work/blog/open-sourcing-our-firmware https://support.system76.com/articles/open-firmware-systems/ https://support.system76.com/articles/open-firmware-systems/
  - oarmstrong 3y ago
    Framework has open sourced the EC firmware, not the boot firmware. The UEFI implementation is still closed source proprietary InsydeH2O software.
    - yencabulator 3y ago
      Yes, but at least they're making soothing noises about going in that direction. Here's notes on coreboot work: https://community.frame.work/t/responded-coreboot-on-the-framework-laptop/791 https://community.frame.work/t/responded-coreboot-on-the-fra... The chromebook variant already runs coreboot, with all changes upstreamed: https://frame.work/blog/introducing-the-framework-laptop-chromebook-edition https://frame.work/blog/introducing-the-framework-laptop-chr...
  - tonoto 3y ago
    I do like the direction that Framework is going and I hope they will deliver to more countries during 2024.
- shzhdbi09gv8ioi 3y ago
  > is there any motherboards out there for AMD64/X86_64 that comes without UEFI/BIOS? Your computer needs UEFI/BIOS for hardware initialization and launching your boot process. There is a open implementation tho, see https://libreboot.org/ https://libreboot.org/ > The Libreboot project provides free, open source (libre) boot firmware based on coreboot, replacing proprietary BIOS/UEFI firmware on specific Intel/AMD x86 and ARM based motherboards, including laptop and desktop computers. It initialises the hardware (e.g. memory controller, CPU, peripherals) and starts a bootloader for your operating system.
man4 3y ago
[dead]
rwaksmunski 3y ago
It is so disappointing that ARM and RISC-V is adopting UEFI, we had a chance of a clean break, but noo, let's make persistent firmware level root kits easy and cross platform with EFI bytecode. Yep, network stack with hard coded web addresses in your firmware, brilliant idea. /rant
- ahoka 3y ago
  These are all solving use cases. What do you suggest hardware vendors should do?
  - rwaksmunski 3y ago
    Apple created a minimal bootloader for their Apple Silicon machines, seems to be working great.
    - Novosell 3y ago
      Apple also controlls their entire software and hardware stack, a bit different
      - surajrmal 3y ago
        Oxide managed to do something similar as well: https://github.com/oxidecomputer/phbl https://github.com/oxidecomputer/phbl
        yencabulator 3y ago
        Oxide also controls their entire software and hardware stack (theirs is open source, at least)... Neither vendor has to worry about modularity or weird configurations.
  - tremon 3y ago
    Open their software drivers and publish accurate specifications.
frantic2821 3y ago
[flagged]
- deleted 3y ago
  [deleted]
1970-01-01 3y ago
UEFI was shoved down our throat, but today I can't think of one example where UEFI is better than BIOS, other than the partition size limit.
- zamadatix 3y ago
  The changes in UEFI are mostly for hardware manufacturers. There's only so much user facing functionality in boot firmware. One other thing it did better enable, through better support of modern hardware and the standardized extensibility, is GUI firmware interfaces. If you get into fancier enterprise hardware use cases the modules are also nice.
- csdvrx 3y ago
  You can use a BIOS with GPT (which remove partition size limit using LBA48) : see EDD 4 page on 4 https://www.fpmurphy.com/public/EDD-4_Hybrid_MBR_boot_code_annex.pdf https://www.fpmurphy.com/public/EDD-4_Hybrid_MBR_boot_code_a... : "Hybrid MBR boot code overview: This annex describes how MBR boot code called hybrid MBR boot code may be constructed to support a GPT disk layout (see UEFI-2.3) in a legacy BIOS system." I'm working on that for one of my projects. A BIOS can use GPT partitions to have LBA48, but MBR partitions standards could laso be changed to use LBA48 instead of LBA32 which cause the limit You could even use the CHS fields to have even more space if needed: there are 3 bytes for the CHS start, 3 others for the CHS end, both are often wasted by storing 0 for LBA32. That said, I still consider UEFI to be better for at least 1) multiplatform support (have different /EFI/BOOT paths to payloads named by their architecture) 2) fallbacks (shell + startup.nsh) 3) defining how the persistence of settings work (efivars)
- Thoreandan 3y ago
  For me: * Not having "extended partitions" as a concept to deal with * OS booting not dependant on "load an MSDOS bootblock from LBA offset X" What I dislike: * Not having a minimal straightforward shell to troubleshoot from * Not letting the UEFI variables be easily user accessible/fixable
  - yencabulator 3y ago
stragies 3y ago
So, does that mean, that I may be able to "root" (my own) mainboards using (only) a maliciously configured DHCP server, and then when booting the target machine trigger a PXE boot? That would be cool for many different reason! And pretty fugly for some others...

152 points by weinzierl 3y ago

devaiops9001 3y ago

It's all so tiresome. Just write these parts in Rust already.

RedShift1 3y ago
Just don't make something so complicated just to boot an OS. The damn thing is an operating system on its own now.
- p_l 3y ago
  It's arguably less complicated than late stage BIOSes were, and I'm not including UEFI Class 1 systems (what many systems people thought still had BIOS actually were)
- weinzierl 3y ago
  I used to think like that but I changed my mind. I don't say UEFI is no over complicated, over engineered mess but I worked on embedded systems for a while and I'd say it's no sunshine there either. Booting a modern OS on modern hardware involves a lot of essential complexity you cannot get away from.
  - temac 3y ago
    The design of UEFI also involves tons of non-essential complexity.
    - weinzierl 3y ago
      Sure, but it is easy to keep essentially simple things simple; accidental complexity is unforgivable in this case. Systems that are inherently complex tend to naturally accrue accidental complexity. It's understandably hard to keep these systems lean. My point is that modern boot systems in general fall into the second category, contrary to other comments that imply the first.
- Avamander 3y ago
  It just is that complicated to bring up all the pieces of hardware in a timely manner and with the right configuration. Not to mention if you want to let user configure things. Just look at say DRAM init: https://www.systemverilog.io/design/ddr4-initialization-and-calibration/ https://www.systemverilog.io/design/ddr4-initialization-and-... Of course you're gonna give that hard task to a memory controller, but then you have to initialise that. This goes on for all the subsystems, with complex interactions and features, all of which need handling. It's not a single microcontroller you're powering on, even if it were, those too require a bunch of initialisation code to function properly.
  - temac 3y ago
    DRAM init as little to do with UEFI or BIOS and Intel probably ships x86 components for more exotic or even allow custom bootloaders. At least at a time they did. I don't know the current situation but when I played with all of that, I saw one of their "Memory Reference Code" in particular the parts in charge of calibration of the memory controller timing, and that was a quite short piece of x86 assembly completely independent from the UEFI architecture insanities. Well because it was written in assembly it had an obvious bug, but that's another story.
- jeroenhd 3y ago
  I disagree. UEFI makes my life, as an end user, so much easier. The amount of times I've needed to buy a different flash drive because the BIOS of a particular motherboard didn't like the way my existing flash drives smelled has gone down to 0. The thing even supports filesystems _not_ formatted by a tool written for Windows 95 that arranges the FAT partition in _just_ the right way to get it recognised. Previously, we had motherboards do the same stuff, except now they called into ROM memory on the network card, and ran a bunch of non-standard, proprietary code to render the fancy graphics and do online updating. I don't believe for a second that things were easier before UEFI standardised it all, they were just hidden from plain view better.
  - p_l 3y ago
    It helps that unlike with BIOS, the modern tooling doesn't have huge amounts of "we never read the spec but it booted on my machine" that was prevalent even with grub2. TL;DR a BIOS doesn't have to boot a drive if there's no primary partition marked "active", no matter whether your boot code uses that or not.
crotchfire 3y ago
Even better, dump that UEFI crap. Not even Rust can fix stupid. Just directboot a static kernel and kexec() the real kernel -- like petitboot has been doing since forever: https://github.com/open-power/petitboot/blob/master/README.md https://github.com/open-power/petitboot/blob/master/README.m... Unless you like writing everything (display drivers, disk drivers, filesystem drivers, network stacks...) twice. Which is where these bugs come from...
- weinzierl 3y ago
  I think Oxide's computers don't use UEFI, but I don't know what they replaced it with. Since they are a Rust shop, maybe something written in Rust, but if not it would also be interesting to know and to know the reasons why.
  - delusional 3y ago
    They have a custom bootloader https://github.com/oxidecomputer/phbl https://github.com/oxidecomputer/phbl that runs without AGESA or any of the normal stack of stuff. From their podcast it sounds like it was quite a bit of work to get it working.
    - ciupicri 3y ago
      Yeah, if I remember correctly even AMD was amazed of what they did.
    - pbronez 3y ago
      Oxide co-founder Jessie Frazelle published an ACM Queue article about the security advantages of open source firmware in 2019: https://queue.acm.org/detail.cfm?id=3349301 https://queue.acm.org/detail.cfm?id=3349301
  - p_l 3y ago
    It works for them because they own the complete hardware stack, and boot only their hypervisor which is also something they control. TL;DR you can make it simple if you close the platform (this is not the same as open source Vs closed source) - open platforms end up developing complex interfaces so thatthey are actually open to end owners.
mkopec 3y ago
Rust won't magically fix every vulnerability and someone would have to pay a team of engineers to rewrite everything.
- jeroenhd 3y ago
  > someone would have to pay a team of engineers to rewrite everything A partial effort has already been made a while back: https://github.com/tianocore/edk2-staging/tree/edkii-rust https://github.com/tianocore/edk2-staging/tree/edkii-rust However, this uses uefi-rs, which is incompatible with TianoCore's BSD+Patent licensing, and therefore cannot be used as reference material, as the wiki page states: https://github.com/tianocore/tianocore.github.io/wiki/Tasks-Add-Rust-Support-to-EDK-II https://github.com/tianocore/tianocore.github.io/wiki/Tasks-... More recent efforts have also been mentioned in the mailing list: https://edk2.groups.io/g/devel/search?p=recentpostdate%2Fsticky%2C%2C%2C20%2C2%2C0%2C0&q=Rust https://edk2.groups.io/g/devel/search?p=recentpostdate%2Fsti... Rust also has a basic standard library implementation now: https://github.com/rust-lang/rust/pull/105861 https://github.com/rust-lang/rust/pull/105861
  - the_panopticon 3y ago
    Some of the challenges in adding Rust to EDKII are described in https://cfp.osfc.io/osfc2020/talk/SLFJTN/ https://cfp.osfc.io/osfc2020/talk/SLFJTN/. There is some more recent work in this space described in https://microsoft.github.io/mu/WhatAndWhy/rust/ https://microsoft.github.io/mu/WhatAndWhy/rust/, too.
jeroenhd 3y ago
I agree, but Rust would've still had several of these vulnerabilities. The integer underflow would've passed in release mode (though you could argue that anything running this low level should spare the extra CPU cycles for checked arithmetic), the infinite loops hanging the system, and the predictable TCP sequence numbers. I'm not sure about the weak pseudo-RNG, because I would expect an existing crate to get imported for that use case, but the same RNG could also be implemented just as badly in Rust. As for the buffer overflow vulnerabilities: I completely agree. These are the most dangerous vulnerabilities and I doubt they would've made it past the compiler had they been written in Rust.

filleokus 3y ago

The disclosure timeline section is worth a read of itself: > 2023-11-14 Quarkslab replied to the prior requests and commentary from various vendors as follows: Stated that the blog post about the issues would contain the technical report submitted to the disclosure coordination forum and a detailed timeline of the relevant events in the disclosure process. It would include proof-of-concept code to trigger vulnerabilities 1 to 7 but NOT exploit code. Reiterated that the purpose of reporting the vulnerabilities was to help vendors identify and fix them, not to debate about the editorial policies for Quarkslab research work.

marcus0x62 3y ago
Pretty typical. Dealing with vulnerability reporting and disclosure has always sucked for researchers, and from my (very) limited experience on the vendor side, it isn't much better there. I'm honestly surprised more of these researchers haven't gone back to the bugtraq/full disclosure model.

tonoto 3y ago

What more vulnerabilities hides in the proprietary UEFI? I have no interest whatsoever to install MS Windows, is there any motherboards out there for AMD64/X86_64 that comes without UEFI/BIOS?

yencabulator 3y ago
You might like these https://frame.work/blog/open-sourcing-our-firmware https://frame.work/blog/open-sourcing-our-firmware https://support.system76.com/articles/open-firmware-systems/ https://support.system76.com/articles/open-firmware-systems/
- oarmstrong 3y ago
  Framework has open sourced the EC firmware, not the boot firmware. The UEFI implementation is still closed source proprietary InsydeH2O software.
  - yencabulator 3y ago
    Yes, but at least they're making soothing noises about going in that direction. Here's notes on coreboot work: https://community.frame.work/t/responded-coreboot-on-the-framework-laptop/791 https://community.frame.work/t/responded-coreboot-on-the-fra... The chromebook variant already runs coreboot, with all changes upstreamed: https://frame.work/blog/introducing-the-framework-laptop-chromebook-edition https://frame.work/blog/introducing-the-framework-laptop-chr...
- tonoto 3y ago
  I do like the direction that Framework is going and I hope they will deliver to more countries during 2024.
shzhdbi09gv8ioi 3y ago
> is there any motherboards out there for AMD64/X86_64 that comes without UEFI/BIOS? Your computer needs UEFI/BIOS for hardware initialization and launching your boot process. There is a open implementation tho, see https://libreboot.org/ https://libreboot.org/ > The Libreboot project provides free, open source (libre) boot firmware based on coreboot, replacing proprietary BIOS/UEFI firmware on specific Intel/AMD x86 and ARM based motherboards, including laptop and desktop computers. It initialises the hardware (e.g. memory controller, CPU, peripherals) and starts a bootloader for your operating system.

man4 3y ago

[dead]

rwaksmunski 3y ago

It is so disappointing that ARM and RISC-V is adopting UEFI, we had a chance of a clean break, but noo, let's make persistent firmware level root kits easy and cross platform with EFI bytecode. Yep, network stack with hard coded web addresses in your firmware, brilliant idea. /rant

ahoka 3y ago
These are all solving use cases. What do you suggest hardware vendors should do?
- rwaksmunski 3y ago
  Apple created a minimal bootloader for their Apple Silicon machines, seems to be working great.
  - Novosell 3y ago
    Apple also controlls their entire software and hardware stack, a bit different
    - surajrmal 3y ago
      Oxide managed to do something similar as well: https://github.com/oxidecomputer/phbl https://github.com/oxidecomputer/phbl
      - yencabulator 3y ago
        Oxide also controls their entire software and hardware stack (theirs is open source, at least)... Neither vendor has to worry about modularity or weird configurations.
- tremon 3y ago
  Open their software drivers and publish accurate specifications.

frantic2821 3y ago

[flagged]

deleted 3y ago
[deleted]

1970-01-01 3y ago

UEFI was shoved down our throat, but today I can't think of one example where UEFI is better than BIOS, other than the partition size limit.

zamadatix 3y ago
The changes in UEFI are mostly for hardware manufacturers. There's only so much user facing functionality in boot firmware. One other thing it did better enable, through better support of modern hardware and the standardized extensibility, is GUI firmware interfaces. If you get into fancier enterprise hardware use cases the modules are also nice.
csdvrx 3y ago
You can use a BIOS with GPT (which remove partition size limit using LBA48) : see EDD 4 page on 4 https://www.fpmurphy.com/public/EDD-4_Hybrid_MBR_boot_code_annex.pdf https://www.fpmurphy.com/public/EDD-4_Hybrid_MBR_boot_code_a... : "Hybrid MBR boot code overview: This annex describes how MBR boot code called hybrid MBR boot code may be constructed to support a GPT disk layout (see UEFI-2.3) in a legacy BIOS system." I'm working on that for one of my projects. A BIOS can use GPT partitions to have LBA48, but MBR partitions standards could laso be changed to use LBA48 instead of LBA32 which cause the limit You could even use the CHS fields to have even more space if needed: there are 3 bytes for the CHS start, 3 others for the CHS end, both are often wasted by storing 0 for LBA32. That said, I still consider UEFI to be better for at least 1) multiplatform support (have different /EFI/BOOT paths to payloads named by their architecture) 2) fallbacks (shell + startup.nsh) 3) defining how the persistence of settings work (efivars)
Thoreandan 3y ago
For me: * Not having "extended partitions" as a concept to deal with * OS booting not dependant on "load an MSDOS bootblock from LBA offset X" What I dislike: * Not having a minimal straightforward shell to troubleshoot from * Not letting the UEFI variables be easily user accessible/fixable
- yencabulator 3y ago

stragies 3y ago

So, does that mean, that I may be able to "root" (my own) mainboards using (only) a maliciously configured DHCP server, and then when booting the target machine trigger a PXE boot? That would be cool for many different reason! And pretty fugly for some others...