2

I am already aware that a BIOS or UEFI malware "activate" only in the OS environment. Is it possible though that a spread mechanism be activated without the presence of the OS, so that it would infect plugged storage drives (IDE, SATA or USB) with the same or other malware ?

Example Scenario:

Let a PC with BIOS or UEFI infected, connected to three storage drives: a SATA disk, an IDE disk and a USB thumb drive.

The PC is started and after a while it prints "No Boot Device". During that stage, could any storage drive be infected by the BIOS or UEFI malware ?

NOTE: I concentrate to the fact that BIOS or UEFI can copy data (malicious or not) to other drives, irrespective of the storage drives file system. If data cannot be copied to other drives while trying to boot, so does the malware (I guess).

4

There is always an operating system, albeit not necessarily a complex one. The BIOS is an OS in the strict sense of the term: it provides access to hardware through an hardware-independent API. The boot code for an OS (or some malware that pretends to be that boot code) uses the BIOS-provided API to read (and possibly write) bytes from the hard disk.

Theoretically, nothing would prevent a piece of malware, installed as "boot code", to use the BIOS to observe the hard disks, locate "infectable" files, and infect them. This would imply making sense of the filesystem structure, which is normally a job performed by the "big" OS (the Windows or Linux or OS X or whatever). If the malware wants to do this by itself, then it must include the code to do so, which can be bulky, or take some non-negligible development effort. Thus, while it is possible, it can be expected that most malware authors, being no less lazy than any other developer, will prefer to avoid it. Booting a "normal" OS and then using its facilities to access files is easier.

The GNU GRUB bootloader is not at all malware; it is a piece of software whose job is to leverage the low-level disk accesses of the BIOS to locate and load in RAM the core elements of an operating system to boot (e.g. the kernel in the case of Linux). As part of its functioning, it includes support for many filesystems. A malware author who wants to locate and infect files in filesystem from a "bootloader" environment would probably reuse parts of GRUB. In any case, GRUB demonstrates that filesystem support code can be compact enough to fit in the constraints of the bootloading environment.

  • On the original IBM PC, there was a BASIC interpreter built into the BIOS. You could perfectly use the PC without any OS at all, or rather with the BIOS as an OS and the BASIC interpreter as a shell. In a scenario like you describe, the malware would take the place of the BASIC interpreter in the original PC. – Jörg W Mittag Sep 23 '15 at 16:23
  • +1 BIOS calls are just as simple to use as syscalls for messing with disk contents. – forest Dec 13 '17 at 6:13
1

Focusing on the simpler of the two, the BIOS boot, the answer is no. To quote this IBM reference IBM link

Historical issues limit the size of a user-supplied bootloader program to slightly less than 512 bytes. Since this isn't enough space to implement all the possible device drivers that might be required to access different displays and storage devices, it's necessary for the BIOS to install standardized software interfaces for all installed, recognized hardware that might be required by the bootloader.

The system needs to load device drivers that will not fit into the memory space of the firmware and thus the OS is indeed present during the stage of boot involved in discovering the drives.

  • You really shouldn't confuse the two. An infected BIOS is definitely larger than 512 bytes, and can intercept a boot loader, being that it occurs at a "lower level" than the boot loader (in fact, the BIOS is what's responsible for calling the boot loader). An infected BIOS could infect any hardware attached to it that is capable of being infected, and the OS might not even be aware of such an infection, as the BIOS is typically set aside as reserved memory by the OS. UEFI could potentially do the same, but that's why Secure Boot was invented. – phyrfox Nov 19 '15 at 15:31
  • Good points thanks for the clarification. Not sure the OP scenario lines up well with your concerns but my response could confuse and needs your clarification. – zedman9991 Nov 19 '15 at 18:57

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.