3

I know that the OS is the boss of programs (once OS is loaded). Is BIOS/UEFI the boss of the everything before OS is loaded? Can an OS be a sitting duck for any BIOS/UEFI related malware?

In other words, can BIOS/UEFI delete or modify OS and other code?

  • 1
    Where did you get the impression modern OS's use the BIOS? Any modern OS doesn't make BIOS calls. DOS and maybe Windows 95/98 made BIOS calls, but no OS since then does. – Steve Sether Aug 21 '18 at 13:02
  • 1
    It's also not accurate to say the BIOS is the boss of anything. The BIOS is just code that interacts with hardware and is really more of a "helper" than something that's in charge. It can handle basic disk operations, and once the OS loads isn't used except by DOS. – Steve Sether Aug 21 '18 at 13:15
  • 1
    Absolutely. The BIOS allows you to connect external peripherals and read them within the BIOS before a traditional OS is loaded. However, the stock BIOS is stored in ROM, with exceptions for firmware updates which are stored in NVRAM. So, you can verify the firmware is doing as it should, without the concern of it acting as malware. – safesploit Aug 21 '18 at 13:59
  • You might like to look at Windows Platform Binary Table (WPBT): download.microsoft.com/download/8/A/2/… – David Aug 21 '18 at 22:14
4

Technically, yes.

The answer, in simple terms, is "yes" to all of your questions.

The firmware (BIOS or UEFI) loads before the operating system. Typically, it looks for a boot sector on your storage devices (internal HD, CD/DVD, USB drives, etc). Then it loads the bootloader specified in the boot sector into memory and passes control to that boot loader, which will get the rest of the operating system up and running.

If the firmware is infected with malicious code, it can read/write anywhere. File permissions are implemented by the OS kernel or the file system driver, so they aren't a concern at all in this situation. This means that you are free to tamper with the OS files as well.

But also, no.

In modern systems, this is very difficult to accomplish, however.

The firmware controls access to the EEPROM, which is where its code is stored. Modern motherboards will usually only accept firmware updates which have been digitally signed by the manufacturer. You would have to defeat this mechanism first if you wanted to tamper with the BIOS/UEFI.

Newer operating systems can validate digital signatures on their files. If you tamper with their files, the digital signature will no longer be valid. E.g., if you enable SecureBoot on Windows 10 and change something it will refuse to boot.

Obviously, you could edit the OS to strip out the digital signature checks if you control the firmware, but it is very difficult to infect firmware for several reasons.

In addition to the built-in protections, the firmware on most motherboards is customized for that individual model or, at most, that particular product line. Writing a firmware hack that applies to a wide range of motherboards is extremely difficult---and may be practically impossible.

All things considered...

It is theoretically possible to tamper with a system in this fashion. The potential for abuse is well understood, however, so the danger is addressed with reasonable technical measures.

People with physical access to your machines could flash the EEPROM chips containing the BIOS code with custom-programmed malware. It takes a lot of resources to orchestrate this, so the average computer user is not at risk.

This type of attack is easily within reach of governments and large criminal organizations. Governments and large firms are at risk, and they generally buy from trusted vendors or certified resellers to reduce the risk of acquiring compromised equipment.

  • UEFI actually makes it pretty easy to write malware that works on a wide variety of systems, but it's not often found in the wild because it's pretty easy to detect (just compare your firmware image with a known-good version), and because extreme persistence is often considered a bad thing by malware authors in many cases, which is why memory-resident malware is so common. Also just a nitpick, but firmware is only rarely stored in EEPROM nowadays. Regular old flash has replaced it. – forest Nov 1 '18 at 8:04
1

The answer here is basically "no," it typically should not. It just calls the bootloader or the UEFI image.

I say typically in the sense of: depending on manufacturer and device it may do some writing features utilized by the BIOS, like writing information to a floppy disk or into memory.

It is theoretically possible that a BIOS could be written that changes setting at specific memory locations that are known parts of the "OS" for specific reasons, although that is not the standard implementation and I don't know of any devices that do that in the standard "PC BIOS" type set up (where firmware and bios overlap in embedded devices gets much more complicated, for example).

The wiki page is actually really good, please review it. https://en.wikipedia.org/wiki/BIOS

0

Once the OS is loaded, the BIOS/UEFI is the boss of the OS.

Not really. When OS is up, every program calls functions from the OS, and OS is really the one executing important code. A program cannot execute anything the OS didn't gave it permission to run.

BIOS/UEFI is more a loader. It reads data from disk, loads data on memory, and executes code in the Master Boot Record. In this moment, whatever code is on the boot record takes control. The BIOS does not have control anymore.

Even if the UEFI/BIOS changes any memory address used by the OS, it will be reverted when the OS initializes and loads itself from disk, as BIOS will not be in execution anymore.

  • Surely BIOS could hijack the OS bootstrap code to keep itself in reign? – John Dvorak Aug 21 '18 at 17:55
  • It could, but the OS would run so slow that the user would see what something is wrong, as BIOS would have to interpret and probably re-route every single instruction from the OS. – ThoriumBR Aug 21 '18 at 17:57
  • @ThoriumBR That isn't true. It could use SMI triggers to only run periodically, or even set up a SMI timer to run every n ticks. It could also modify the OS by hijacking the IDT to hook various relevant interrupts (keystrokes, disk writes, etc). The BIOS is always still in charge even at runtime by virtue of SMM. And I suppose also ACPI tables, though that attack vector is more limited while still being more complex. – forest Nov 1 '18 at 8:06

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.