LightEater Malware Attack Places Millions of Unpatched BIOSes At Risk

Mark Wilson writes Two minutes is all it takes to completely destroy a computer. In a presentation entitled 'How many million BIOSes would you like to infect?' at security conference CanSecWest, security researchers Corey Kallenberg and Xeno Kovah revealed that even an unskilled person could use an implant called LightEater to infect a vulnerable system in mere moments. The attack could be used to render a computer unusable, but it could also be used to steal passwords and intercept encrypted data. The problem affects motherboards from companies including Gigabyte, Acer, MSI, HP and Asus. It is exacerbated by manufactures reusing code across multiple UEFI BIOSes and places home users, businesses and governments at risk.

Comments

Code reuse exacerbates the problem?

[LazLong]

Manufacturers/vendors don't write their own BIOSs; they license them from the likes of Phoenix Technologies and Insyde. These licensors don't write a completely new BIOS and bits for each licensee, let alone for each motherboard and their variants. As such, of course there is code reuse. Imagine the probable security issues there would be if each Vendor, let alone motherboard, received a BIOS that was written from scratch. QA would be a nightmare, as would the security of the code.

The problem isn't the reuse of code. The problem is that the code that was reused had security vulnerabilities.

Re:Hardware is trusted

[aaaaaaargh!]

It would be easy to prevent such attacks by requiring a physical switch to make any changes to the BIOS possible. But that would give power to the end users instead of big industry, and we cannot have that, can we.

Re:Hardware is trusted

[DarkOx]

Not sold. Sticking with something like BIOS does not mean sticking with BIOS. Its time to drop the legacy support, sure. Sticking with a small amount of boot code to fire up the storage controller and jump to boot loader, set some memory timings etc is going to more secure than a massive interactive application that UEFI is.

Fewer inputs mean fewer inputs to sanitize and less opportunity to screw it up.

Re:Hardware is trusted

[Jesus_666]

It'd be nice if the next iteration of EFI had a more robust upgrade security design.

Something like this: Firmware upgrades are not possible from inside the OS. At all. Instead there's a switch on the mainboard that is only accessible when the computer has been physically opened. When that switch is on, EFI will refuse to boot any OS and all onboard SATA/SCSI controllers are physically disabled. EFI will scan every USB port* for a FAT32-formatted mass storage device containing a file with a certain filename, which is then displayed for your approval, checked and installed. While the switch is off, changing the firmware should be prevented in hardware, such as by detaching a certain line required to write to the flash chip. (Settings should be stored on an unprotected chip and can be changed while the computer is bootable.)

You're in a corporate setting and need to update 16.000 identical desktop computers all at once? Make sure the computers have an enterprise-ready mainboard that can pull the update from the network (e.g. using something similar to BOOTP). You'll still have to toggle that switch and confirm the prompt. That's as convenient as it should get; after all, if there is any chance that the firmware is modified while an OS is loaded, any successful attack on the OS leaves your firmware in a potentially compromised state.


* Yeah, I know, USB also has infectable firmware. Unfortunately, I don't know of a reasonable mass storage standard that doesn't. And making people physically swap PROM chips won't fly.

Re:Hardware is trusted

[Kjella]

I think UEFI has two different tasks confused. One is to boot my OS, which should just involve pointing it to the right storage device and loading X bytes into memory. The other is to provide a system configuration environment where I can boot and other hardware settings and there I want a rich environment. I want to be able to use my USB mouse and Bluetooth keyboard in a GUI, wired and wireless drivers for PXE boot, storage and RAID drivers, you name it. Basically it is a little OS in itself, running off motherboard firmware.

Now I have the impressions it's doing all this loading of a micro-OS with complex drivers only to finally hand over control to the real OS. Why? Maybe the OS wants to run a newer and better Bluetooth driver and now it can't because UEFI is running an old version. And if you do update the UEFI driver and break shit, you also broke your boot configuration. Just do the minimum requires to get the boot image, load it into memory and hand over control to the OS then get out of the way. If the boot fails, then you can launch the full configuration environment.