AMI PC firmware upgrade scare: The global security meltdown that wasn't A computer hardware maker that leaked the source code to American Megatrends Inc's PC firmware did not reveal private keys for signing firmware updates - contrary to early reports. The blueprints for AMI's UEFI firmware were found by a security researcher on a wide-open Taiwanese FTP server along with what appeared to be …
The PC bios has been disassembled and clean room rebuilt many times. Having the source code can help to find weaknesses, but a black hat still needs to look at the machine code dump to confirm one. In any case, if they were trying to make it very secure, they ought to publish it for others to analyse for weaknesses, obscurity is not security.
The BIOS/UEFI code for PCs really should be open source, just so you can see what is going on and theoretically fix bugs.
That is NOT the same as having it unsigned or no restrictions on how it is updated, but again it ought to be possible to change it should you want. To stop malware writers, then having an internal jumper that you must bridge to allow such an override would be a pretty effective way of blocking all but the determined spies (or terminally stupid users).
It will be interesting to see how good (or otherwise) this code is once security and hardware folk have had a look at it.
Well open source by itself won't fix the problem.
One problem is that UEFI is _huge_ and only maintained by a couple of people. UEFI is about as large as the Linux kernel. It is very hard to check that amount of code unless you actively involve the community in writing/improving it. You need free software instead of just opening up the source code.
That leads us to the second problem, signing. If the code is signed it is very hard for people just to tweak it to try it. Furthermore since when they make an error their system may be bricked, it's hard to experiment. That all makes the community involvement hard.
Well I currently cannot find the blog I've read that on, I think it was from one of the kernel developers.
But just think about it. All the BIOS does is initializing the hardware and providing a nice text-based software interface.
Now EFI adds bloated structures with binary interfaces. You suddenly can load new elements into your firmware. You often have a TCP/IP stack. You must have a file system.
Actually the Monty Pythons provided us with a great metaphor for the problem.
http://www.youtube.com/watch?v=zKhEw7nD9C4
UEFI security is just like the Black Knight. He's stationed at a bridge. (as seen by the tent and the fire) And does his best to keep people from crossing it. And at first he succeeds with it. That's just like UEFI secure boot which tries to bring security by restricting the boot process and restricting the firmware you can boot.
Then Sir Lancelot comes and fights with him, hacking off limb after limb while the knight doesn't seem to understand that even after having lost the first arm he essentially lost. This is what we are seeing here. First the Samsung debacle which sheds some light on the bad code quality of the UEFI code, then a careless vendor leaving the secret signing key lying around.
In the end we see Sir Lancelot crossing that bridge. It's not a large bridge, with much less effort and risk than fighting the Black Knight, he could have easily crossed it at another point. So fighting the Black Knight was entirely pointless. It's similar for UEFI. Sure once you managed to change the boot code you could do just about anything with ease, however in order to access the boot process at all, you must first bypass all the security measures you want to bypass by for example virtualizating the kernel. So you must already be at the goal to start your journey. You already must be root to begin with it.
One really wonders why they haven't learned from history.
Any miscreant with this private key could therefore sign his or her own malicious firmware and permanently install it on a victim's machine by tricking the user or compromising the PC.
Or exactly as can be done right now without any signing keys or other fannying around, as I like to think of it.
What stops it happening is that your malware will only work on the motherboard it's written for, which puts it in the "chocolate teapot" category for the commercial bot-herders who put the effort into this sort of thing. Sort of the exact opposite of the boot-filling potential of a java or adobe exploit, if you will.
If you were, say, a spook interested in getting an ear into one specific machine it has legs of course.......
Well UEFI would theoretically enable mainboard independent malware. That's one of it's main features. You can have binary modules which are independent of your hardware.
And actually the more interesting vector would be the graphics card. There are only very few vendors and the graphics card BIOS is nearly identical on all of them. It includes a driver so your operating system doesn't need one for unaccelerated access.
This malicious code runs underneath the operating system, and could therefore set itself up to spy on everything the user does without being spotted.
It could inject very early in the boot process but I thought OSes kicked the BIOS out of the address space fairly swiftly. They certainly had to many moons ago because they were only designed to support DOS. Have we come back around now? Do modern BIOSes actually provide services that are useful to a modern OS?
The problem is not the "BIOS" that most OS care not about, but that it could launch a hypervisor style of rootkit before ANY operating system has booted, and if implemented well that is virtually impossible to detect or get rid of.
Same reason that if you have an infected PC, always boot from a "live CD" like the BitDefender one to attempt an anti-virus based removal. Or to nuke it from orbit...
"Do modern BIOSes actually provide services that are useful to a modern OS?"
Yes, you'd be surprised how much of your BIOS actually still runs.
For example when you have an USB keyboard and/or mouse connected to your PC and you run a version of Windows that doesn't support USB (i.e. most of them). Your BIOS will emulate a keyboard controller with an AT keyboard for your operating system. It's called "Service Mode" and is a separate mode which can emulate hardware for your OS.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
