▲ 200 points
back
103 comments
Didn't know what UEFI was, so here it is:
" UEFI and BIOS are low-level software that starts when you boot your PC before booting your operating system, but UEFI is a more modern solution, supporting larger hard drives, faster boot times, more security features, and—conveniently—graphics and mouse cursors.
The UEFI/BIOS loads when your computer starts up, and the BIOS is responsible for waking up your computer’s hardware components, ensures they’re functioning properly, and then runs the bootloader that boots Windows or whatever other operating system you have installed.
You can configure various settings in the BIOS setup screen. Settings like your computer’s hardware configuration, system time, and boot order are located here.
The BIOS goes through a POST, or Power-On Self Test, before booting your operating system. It checks to ensure your hardware configuration is valid and working properly."
Source: https://www.howtogeek.com/56958/htg-explains-how-uefi-will-r...
Thanks for this. I had a generally good idea about this, but despite seeing the word for many years, never actually knew what POST stood for before this comment. I'm not even sure I knew that it was an acronym...
For anyone wanting to know how UEFI actually works, I always recommend this article: https://www.happyassassin.net/posts/2014/01/25/uefi-boot-how...
This should be common knowledge among everyone using a computer. It just makes sense to know how your device operates, and it's not hard to learn.
Having been the go to guy for fixing anything remotely computer related, I got sick of it and I just wish everyone could fix their own stuff :D
I get the feeling UEFI can never be entirely secure with the set of functionality it offers and thus huge surface it is exposing.
Call me crazy, but security means doing only what is necessary and no more, in particular in this early part of starting up a computer system.
UEFI needs ~complete access to the machine so it can initialize hardware devices and pass control to the OS (which also has ~complete control of the hardware). How do you think sandboxing it would work, practically?
As demonstrated by MoonBounce: https://securelist.com/moonbounce-the-dark-side-of-uefi-firm...
We've past this point with Intel ME, AMD's counterpart, and UEFI being an embedded OS which can run arbitrary binaries with free pass to everything on the system, almost ~10 years ago.
The processors and the platform is so complex now, even with a secure UEFI, there are many points into the system both with add-on cards and your Ethernet port and bowels of the platform which has many controllers with Ring -1 (and deeper) access, where Ring 0 is the OS kernel level access.
Yeah I really don't understand why this crap needs to be so capable.
You can already do all sorts of tricks with net booting, any HTTP stack needs can be deferred to run in the OS.
I worked extensively with UEFI in a past job and every implementation I could find had large bugs of some kind. It is fine at booting the system but managing it is a nightmare, and it seems like UEFI prompt is designed to be as obtuse as possible. And I didn't even know it could do HTTP calls!
This made me wonder if somebody got Doom to run under UEFI, and sure enough:
UEFI is like the ugly son of MS-DOS and Windows. Anything that can run under MS-DOS with a DOS extender can run under UEFI.
A friend of mine ported QEMU in order to run x86 boot ROMs on ARM systems.
was about to comment this. Now I have to find ridiculous things to run on uefi.
Has anyone implemented audio output on a modern x64 machine under UEFI, e.g. using the typical Realtek on-board audio? If so, I'd like to get a GUI with a screen reader working under UEFI sometime, both for the challenge of getting into bare-metal programming, and because as far as I know, nobody has made a PC boot process and firmware setup UI (what we used to call BIOS setup) accessible to blind people.
See this project: https://github.com/Goldfish64/AudioPkg
It would be very interesting project, because UEFI also puts emphasis on unified UI stack - yes, you can do stupid bling setup interface still, but there's somewhat unified UI toolkit available + standardised ways to create configuration options for devices.
This way, a screenreader could hook into the UI toolkit and provide a good interface.
Now imagine a whole working set of software, and some encrypted storage, running in UEFI, while the "real OS" with some games and office apps is only loaded to plausibly deny the real use.
A few thoughts: yes, UEFI is a large attack surface. Secure Boot mitigates a lot of that - if it's turned on, the vast majority of UEFI functionality is only accessible to signed binaries. If you're running untrustworthy code in your boot environment then it's already in a position to just overwrite the firmware, there's no memory protection here. But UEFI doesn't entirely go away after the OS boots, there's some number of runtime services left that the OS depends on. http://blog.frizk.net/2017/01/attacking-uefi-and-linux.html is a demonstration that if you're able to modify those then you can compromise the OS. There's also, of course, all the code in SMM which can just do whatever and may have been audited but possibly hasn't been.
But honestly overall BIOS was a bigger concern than UEFI. It's easy to forget, but a lot of the BIOS hooks are still available at runtime - https://github.com/mqudsi/lrmi is an interface that lets you call them from Linux. It's reasonable to worry about the attack surface exposed by UEFI runtime services, but BIOS software interrupts are frankly even weirder. The reason we largely didn't worry about them is that you normally have to be root to call them, which is also the case for UEFI runtime services and most SMM interfaces. And SMM definitely predates UEFI, so getting away from UEFI complexity wouldn't save us there.
And there's been plenty of meaningful security work done in the UEFI space lately. There's support for proper IOMMU setup so that you can boot off Thunderbolt without any Thunderbolt device just being able to DMA all over your firmware. The NX bit is supported. There's support for stack canaries. There are best practices for SMM behaviour. https://uefi.org/sites/default/files/resources/UEFI%20Firmwa... covers a bunch of this.
If we were designing firmware for maximum security then I don't think anyone would argue we'd come up with UEFI. That doesn't mean that we should be nostalgic about BIOS, which was a smaller attack surface but provided no meaningful security.
TIL: It's possible for UEFI code to access the internet. What could possibly go wrong?
How did you think netbooting support works?
UEFI made it quite simpler by making it so that network cards only have to bring a driver in OPROM instead of whole stack as before, and this allowed important improvements into boot process (like HTTPS instead of TFTP)
> TIL: It's possible for UEFI code to access the internet.
Quite surprising to see lots of tech-oriented users here finally discovering UEFI having access to the internet after years of even the basics like "Internet Recovery" being used on Apple Macs or even sysadmins using netbooting on diskless systems.
There is always a IP/Net stack section in the UEFI menu on nearly every modern PC which gives you this hint, but it isn't useful for the 95% of users, except for sysadmins, recovery, security and even malware writers.
> What could possibly go wrong?
Indeed. A lot can go wrong. I bet someone will do a Wordle clone in UEFI next.
How about this heap overflow bug in the UEFI bitmap (BMP) library: https://nvd.nist.gov/vuln/detail/CVE-2021-38577
Exploitable via network, no user interaction and no special privileges required. Scores 9.8 on a scale of 10 for severity from NIST. That's what happens when this stuff is done in such a highly privileged environment - simple bugs become security nightmares.
For comparison, Heartbleed scored a 7.5: https://nvd.nist.gov/vuln/detail/CVE-2014-0160
Secure boot and signed firmware won't save you, and in fact it could make things worse since it means even well-informed and capable users won't be able to fix it on their own. They're utterly helpless until their vendor fixes it and publishes an update.
PXE boot has been supported since before UEFI was a thing.
Wasn't it always possible? If it can boot a full-blown OS that can access the internet, it has to be able to access the internet on its own.
this is the bloat free software that i need in my life
If this allows me to use “latest tweets” chronological view as default instead of the brain dead “home” view I’m totally setting up a laptop with this. The official twitter clients are more atrocious each day (spaces? Home by default? 95% promoted tweets in my timeline? List suggestions I don’t care about?)
There are quite a few third party client who work quite well.
Twitter sends me fake notifications, despite me disabling them, then they follow up with notifications to check out my missed notifications.
/s
Gather around children. Let me tell you a story from long long time ago.
Two one eyed giants, Intel and Microsoft got together and decided that they should be in control of your machine, not the other half giants, like AMI, Award,Phoenix, DTK, and even a full giant but nobody cared about her, IBM.
So they convinced everyone there was no space on the BIOS any more, and they had to shift much of the code outside onto a boot device, usually an HDD. 'Think about all the speed and ability to update quickly' they said to the peasants, and the local magistrates in the form of media gobbled it up, and continue to spread this news. There were some peasants that freaked out, pointed out the problem, but quickly were shouted down and jeered at by the crowd. 'We want faster! Stop spreading misinformation.'
And, the two giant indeed forced the development of EFI then UEFI. There is nothing Unified about it. But, guess what? That was not good enough either, because some peasants figured it out how to manipulate the UEFI, and the two giant didn't like that. So they went back to the half giants and discussed what to do.
And, lo they came up with an brand new idea! What if we put all this information into a chip, and make it hard to read! We will call it, BIOS! For good measure, for peasants that want more power, we will even throw in another one, and we will call it Baseboard Management Controller, but we will let you call that all kinds of different names! To make it even more entertaining, in larger cities where peasants are promoted to the rank of "enterprise", some host board adapters will also run OSes themselves for the fun of it.
And this is how we got to today. When your computer runs, the BIOS with a full OS can be running, next to it, the BMC with a full OS could be running, on top of the BIOS you can have UEFI running, the HBA OSes running, and finally your very safe and secure OS running.
/story
I have taken artistic liberty (like UEFI most often runs on the same CPU,while BMC & HBA run on their own, and such), but the gist is true.
An enterprise class host can be running many fully functional OSes, potentially with full network stack. This is why "zero trust" network implementation is so important.
> and finally your very safe and secure OS running.
That's the one running on the Intel Management Engine, right? Or at least Intel would like to believe that's the case.
Jokes aside, I may be missing something. The BIOS came way before UEFI did. What am I missing here?
What would be the purpose of this? A no-GUI client that’s loaded before the OS?
File this project under: the engineers were so preoccupied with whether or not they could, they didn’t stop to think about if they should.
Would it be possible to run light weight apps/containers based on Wasm/Wasi? What are the limitations of UEFI?
> You need to enable "HTTP Protocol Stack Support" in your UEFI.
This is potentially not the best idea in the world...
Ya'll ain't seen nothing yet. For a time the leading UEFI vendor, Phoenix Technologies, had a web browser in their UEFI BIOS. Some photos from WinHEC 2005 can be seen here: https://www.anandtech.com/show/1670/8
This was part of their "eBetween" UEFI BIOS that enabled them to show ads during boot-up (seriously) and also install software to Windows with what they called "Virtual Bundling Technology": https://indexarticles.com/business/business-wire/phoenix-tec... and https://www.cnet.com/tech/tech-industry/phoenix-jumps-on-web...
tl;dr version: UEFI can download software from the internet, copy it to the Windows partition, edit the registry, and even add desktop icons and IE bookmarks. Phoenix sought to productize this.
If you've ever seen a Windows PC where you just couldn't get rid of certain pieces of software or icons, it may have been eBetween at work. This is effectively the same thing as the persistent malware attacks described in numerous security blogs. Phoenix has since rebranded their UEFI codebase to (irony alert!) SecureCore.
Anyone have a favorite guide/blog post/whatever for getting started with UEFI applications?
Not a tutorial but good info and keywords https://www.intel.com/content/dam/develop/external/us/en/doc...
Also this might be helpful: https://pete.akeo.ie/2015/01/easily-create-uefi-applications...
and if you choose edk2: https://www.tianocore.org/
https://wiki.osdev.org/UEFI
There are several pages here under the UEFI tag. There are also some application guides and a few polished bootloader documents.
Doom for UEFI, twitter for UEFI, what's next? A video player for UEFI?
This sounds like a perfect command and control setup for malware.
It's not really a good option, however SMM mode could be (you'd need to figure how to do network calls, though). The only thing changed by UEFI in this case is unified interface to register SMM components (You can have UEFI system with no SMM).
Exactly. My first thought was bootkit as standalone C2 would not be that useful
I'm impressed when they have VirtualBox or qemu running in UEFI, sandboxing my real OS.
Why would you want qemu running in UEFI, rather than have qemu booted from UEFI? (more specifically run qemu on xen booted from UEFI, I think is what you'd want).
Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.
My only question is; why? Don't get me wrong, it is cool, but do people actually use it?
As for why: Probably because it’s a cool hack.
Does anyone actually use it? Probably not.