11

Can an OS vulnerability be exploited to install BIOS/UEFI/firmware malware (such as a keylogger)? I know BIOS is a "deeper" level than the OS. I know firmware based keyloggers exist. I know they can be installed by an adversary flashing the BIOS. But can an OS i.e. Windows write to the firmware? Could a hacker theoretically (whether or not this has ever been done) exploit a security vulnerability in a victim's operating system and use that to flash the BIOS or otherwise install malware into the firmware? And if not, then how could someone remotely flash/infect the BIOS? And how can that be protected against?

  • 1
    What firmware are you referring to? The core of this question seems to me to understand how the relationship between OS and BIOS works. – Tom K. Feb 18 '18 at 21:58
  • Emma, how does one update the BIOS in normal operation? There is a ton of material out there for every one of your questions. Yes, there is BIOS malware. – schroeder Feb 18 '18 at 22:06
  • You should check the Chernobyl virus from the 90's. It was unique in that it overwrote the BIOS from the OS, effectively bricking the motherboard and making the PC unusable – DemonessJess Feb 19 '18 at 3:33
13

Firmware configuration

Writing to the BIOS is a privileged operation, only doable by the superuser. Many BIOSes attempt to prevent this, for example by locking the SPI write bit and limiting the ability of SMM to interact with the BIOS. Unfortunately, there are so many ways to modify the BIOS that many (most?) firmware vendors do not adequately lock down the configuration, allowing the superuser to modify it. Whether or not a given system has a vulnerable BIOS can be determined using the CHIPSEC framework. It scans the system for common misconfigurations and reports them, along with the implications. It will report on whether or not all the required lock bits are set at boot. In many cases they simply are not.

This is not necessarily sufficient for protecting against an attacker with privileged access. A sufficiently advanced attacker, even if they cannot modify the BIOS, may still be able to modify option ROMs or even storage device firmware. At the very least, they may be able to physically damage the computer by repeatedly writing to non-volatile write-sensitive storage such as NVRAM. But regardless of other remaining risks, locking down the BIOS, or at least determining if it is locked down, is the first step.

Additionally, privileged tasks have access to low-level interfaces on the system. There has been an increase in firmware security research lately which has shown that, even with all locks properly configured, the sheer complexity and difficulty in patching systems makes bugs pervasive. This can manifest itself simply as ways to bypass firmware security, or even ways to get even more privileges.

Measured boot

Many modern systems come with Intel BootGuard, a technology which allows a signed BIOS to be verified by the physical chipset itself before booting. While it is not perfect, it makes attempts to prevent unsigned firmware from running, even if the firmware is able to be modified. This requires a modern system that has been pre-assembled by an OEM. If this is not the case, a TPM can be used instead to verify the integrity of the BIOS, alerting you if there have been any modifications.

BootGuard works by digitally signing the BIOS. The key used for verification is burned into the PCH at assembly time by the OEM. When the system boots, the BIOS' signature is verified by the public key. An attacker is not able to modify this public key as it is written to OTP (one-time programmable) fuses.

The TPM works a little differently. A read-only bit of code in the BIOS called the CRTM sends a copy of the BIOS hash to the TPM. This then happens with the rest of the system's configuration, such as boot settings, option ROMs, and the MBR. If all these hashes match the expected value, the TPM will unseal a secret value it has been securely storing. This value can be an encryption key necessary to finish booting, or it can be a secret value known only to you, such that an attacker, even one who can modify the contents of the screen, cannot impersonate an unsealed TPM.

Summary

It is not always possible to effectively write protect your firmware, whether from hardware or software threats. In general, if an attacker has malicious local (even if not physical) access to your machine with high privileges, they can typically do whatever they want. The best solution is to prevent them from getting high privileges in the first place. If that is not possible, then there are only three solutions:

  • Ensure your BIOS locks all required bits, as can be determined by CHIPSEC.
  • Use a system with Intel BootGuard supported and enabled.
  • Make use of a TPM to provide measured boot. This is not always practical.
  • All vendors have tools today that can rewrite the BIOS/EFI from any OS. That makes altering a BIOS a child's play. – Overmind Feb 13 at 9:34
  • @Overmind This depends on the write protect bits. A well-designed system will lock the bits at runtime and disallow flashing the BIOS from the OS, only permitting updating from within the UEFI shell. – forest Feb 13 at 9:35
  • True, hopefully we won't see too many cases like this one: bleepingcomputer.com/news/security/… – Overmind Feb 13 at 10:09
-2

Short answer: most system software that can be updated at all can be updated from within the context of a running os.

Now, there's extensive protection at work (at least on pc motherboards / modern x86) with things like negative numbered rings only accessible through SMI and so on - but these have been shown to be flawed in multiple instances, and in the end, even a legitimate firmware upgrade might be malware.

So yes. Standard question: "I have a complex system; is it vulnerable?", standard answer: "Yes. Next! "

  • The issue isn't that these protections are flawed, but that there are many protections, and they all have to be properly configured. Most BIOS vendors just don't care enough to set them all. – forest Feb 20 '18 at 5:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.