I am currently a bit confused, I have read today an article about the BIOS-rootkit Lighteater made by John Loucaides and Andrew Furtaki. In their presentation 'How many million BIOSes would you like to infect?' they explain what they have done. They spoke at the CanSecWest this month. This is real serious, as in a concept of proof they were able to get a a private GPG key in plain text from memory, although using Tails that is just running in RAM.

They said: "The high amount of code reuse across UEFI BIOSes means that BIOS infection is automatable and reliable". As far as I know, UEFI is the successor of the old BIOS. So I am a bit confused about these two terms. What I do not understand is, they say that the UEFI is vulnerable, is the old BIOS vulnerable to these kind of attacks, too? I am asking because I still have an older BIOS and not UEFI, am I vulnerable to these attacks too and have to quickly flash a newer version on my board, if one exists? And what are you doing about this?

  • A related answer
    – RoraΖ
    Commented Mar 24, 2015 at 18:17
  • 1
    But Lighteater is able to bypass the BIOS flash protection, so they are able to reprogram portions of memory, could they not even reprogram UEFI, as long as you are not mechanically prevent it with a bios flash jumper. They have tested this with Win10 and Tails, so I guess SecureBoot was not preventing anything. And as it is a bootkit it hooks up when UEFI starts, so I doubt that Secure boot is useful.
    – Greeneco
    Commented Mar 24, 2015 at 18:35
  • 3
    Basically, both BIOS and UEFI are vulnerable to a targeted attack, but UEFI makes it even easier because they are more standard and a single malicious binary can work across many UEFIs, where as in BIOS it's more limited and a single binary can only work on the exact same system board. So it just becomes cheaper for attackers to compromise a large amount of systems because they only need to develop a single binary, vs many binaries for different systems.
    – user42178
    Commented Mar 24, 2015 at 19:58
  • 1
    They're finding vulnerabilities that allow them to hook kernel-mode functions from untrusted address space. As they stated at the end of their presentation; allowing SMM code to read/write arbitrary memory space is an architectural problem. It's no reason not to upgrade to something like Secure Boot to help prevent other types of rootkits.
    – RoraΖ
    Commented Mar 25, 2015 at 15:41
  • 2
    Secure boot is enforced by the UEFI. If you compromise the UEFI you can easily disable secure boot.
    – user42178
    Commented Mar 25, 2015 at 23:19

1 Answer 1


First, there's a terminology issue when talking about this stuff. Strictly, 'BIOS' and 'UEFI' are different programming interfaces for the firmware present on PC motherboards. However, in a PC context, 'BIOS' is often used to refer to the firmware irrespective of its API -- that is, "UEFI BIOSes" should strictly read "UEFI firmwares".

(Just to be clear: that's not me picking on your choice of words. This ambiguity is rampant throughout discussions on this subject.)

However, realistically, what @andré-daniel said is right: a lot of PC firmwares are vulnerable to these kinds of attacks, because they're not particularly well-hardened. UEFI just makes it easier to attack in an automated fashion because there's a lot more code sharing and reuse between UEFI firmwares from different motherboard manufacturers than there was between BIOS firmwares.

Remember, though, that firmware attacks require code running on the machine, and it needs to be able to get into kernel mode. So preventing malware from running on your computers in the first place is of paramount importance. Safe browsing habits, anti-viruses, and up-to-date software (especially the OS kernel) will all help.

So, in short, yes, you probably are vulnerable to these attacks. Yes, flashing a more recent firmware is likely to help. But you're dependent on the motherboard manufacturer to release updates, which manufacturers are terrible at doing. So there's actually scarily little anyone else can do, apart from try to prevent malware from running.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .