Can a virus destroy the BIOS of a modern computer?

Question

In the late 1990s, a computer virus known as CIH began infecting some computers. Its payload, when triggered, overwrote system information and destroyed the computer's BIOS, essentially bricking whatever computer it infected. Could a virus that affects modern operating systems (Like Windows 10) destroy the BIOS of a modern computer and essentially brick it the same way, or is it now impossible for a virus to gain access to a modern computer's BIOS?

Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/91977/discussion-on-question-by-user73910-can-a-virus-destroy-the-bios-of-a-modern-com). — Rory Alsop, Apr 04 '19 at 12:42
Some (or most?) desktop motherboards have a ROM used to recover the BIOS from some form of media (in the old days, floppy disks, these days, USB sticks, maybe cd-rom). The ROM can't be modified, however recovery usually requires opening the case and moving a jumper to boot into BIOS recovery mode. I don't know how laptops deal with this. — rcgldr, Apr 04 '19 at 16:11
yes but from an attacker perspective it is a waste or resources... More info on a rootkit for UEFI as an example in the bellow paper... https://www.welivesecurity.com/wp-content/uploads/2018/09/ESET-LoJax.pdf — Hugo, Apr 04 '19 at 12:15

Philipp · Accepted Answer · 2019-04-03T10:37:47.497

Modern computers don't have a BIOS, they have a UEFI. Updating the UEFI firmware from the running operating system is a standard procedure, so any malware which manages to get executed on the operating system with sufficient privileges could attempt to do the same. However, most UEFIs will not accept an update which isn't digitally signed by the manufacturer. That means it should not be possible to overwrite it with arbitrary code.

This, however, assumes that:

the mainboard manufacturers manage to keep their private keys secret
the UEFI doesn't have any unintended security vulnerabilities which allow overwriting it with arbitrary code or can otherwise be exploited to cause damage.

And those two assumptions do not necessarily hold.

Regarding leaked keys: if a UEFI signing key were to become known to the general public, then you can assume that there would be quite a lot of media reporting and hysterical patching going on. If you follow some IT news, you would likely see a lot of alarmist "If you have a [brand] mainboard UPDATE YOUR UEFI NOW!!!1111oneone" headlines. But another possibility is signing keys secretly leaked to state actors. So if your work might be interesting for industrial espionage, then this might also be a credible threat for you.

Regarding bugs: UEFIs gain more and more functionality which has more and more possibilities for hidden bugs. They also lack most of the internal security features you have after you have booted a "real" operating system.

Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/92028/discussion-on-answer-by-philipp-can-a-virus-destroy-the-bios-of-a-modern-compute). — Rory Alsop, Apr 05 '19 at 08:03

score 47 · Answer 2 · answered Apr 02 '19 at 08:37

Yes, it is definitely possible.

Nowadays, with UEFI becoming widespread, it is even more of a concern: UEFI has a much larger attack surface than traditional BIOS and a (potential) flaw in UEFI could be leverage to gain access to machine without having any kind of physical access (as demonstrated by the people of Eclypsium at black hat last year).

score 20 · Answer 3 · answered Apr 02 '19 at 19:39

20

Practically speaking, a virus is software, so can do anything that any other software can do.

So the simple way answer to this question, and all others of the class "Can viruses do X?" is to ask "Does software currently do X?"

Such questions might include "can a virus walk my dog?" (not without a dog-walking robot); "Can a virus get me pizza?" (yes: this is regrettably not the main focus of most virus authors, however).

Are BIOSes (UEFI) currently updated using software? The answer is, yes they are. Mine updated last night, when I rebooted.

And so the answer is yes.

By the same logic, viruses can also cause (and historically have caused) physical damage to your CPU, hard drives, and printers.

Home automation systems and driverless vehicles are also possible targets for physical damages, but I know of no viruses which have done so.

answered Apr 02 '19 at 19:39

Dewi Morgan

1,340
7
14

2

I wouldn't mind much if my personal information was used by malware developers to order me free pizza and nothing else. (+1 for useful reasoning) – Marc.2377 Apr 02 '19 at 23:23
7

@Marc.2377, I would not mind much if *your* personal information was used to order *me* free pizza… :-) – sleblanc Apr 03 '19 at 03:54
2

Modern viruses will have a very hard time causing physical damage. At most, they could wear down hardware a bit by running the CPU really hot, which shortens useful lifetime, but it's not common for it to be able to cause _damage_. In the past that wasn't the case though. See "the poke of death". – forest Apr 03 '19 at 07:33
1

@Forest I agree... though "hard time" applies to most virus stuff, as they rely on the undocumented, unanticipated behavior of their exploits. I'd argue as devices get more complex, maliciously bricking them gets more feasible (through thermal cycling, read-write cycles, vibration, overheat, overvolt, overclock, firmware...). That we don't see more device-destruction attacks is I suspect more because malware authors are uninterested in them; they make for a fun demo at a hacker con, but are essentially useless in a real virus or attack. – Dewi Morgan Apr 03 '19 at 15:20
2

@forest Aren't the fans and cooling systems software controlled these days? I'm not sure, but I bet you could somehow foul the CPU or GPU fan from software. Russia destroyed generators remotely by toggling them on and off at a resonant frequency--I bet there are similar tricks that could kill your monitor pretty quickly. Platter hard drives can definitely be trashed by spinning them up and down repeatedly, solid state drives are vulnerable to repeated read/write cycles. I bet there is a lot a motivated hacker could do.. – Bill K Apr 03 '19 at 17:55
1

Ransomware that makes its demands via a note buried in an apparently free pizza. Now there's an idea! – Dawood ibn Kareem Apr 03 '19 at 19:58
But I wanted wings not pizza. – Mark Schultheiss Apr 04 '19 at 13:01
2

I think we'd need to define scope of "cause physical damage" before we decided if it was possible/plausible. If you constrain the definition to literally damaging the computer running the code, that's pretty narrow and I think @forest is right. If you include physical damage in a more general sense, it's much easier to imagine scenarios where an infected computer that's controlling something else (power plant, traffic lights, mass transit system, water treatment plant, etc) could easily cause major physical damage. – dwizum Apr 04 '19 at 16:00
@dwizum Feels to me like "Forest is right" is a reliable rule of thumb, though not quite not a truism, as there're edge cases, differences of experience and interpretation, etc. I interpret "destruction" in the OP to include any bricking where specialist or replacement hardware would be required to fix. But I agree we should interpret "physical damage" more strictly: but still, thermal cycling, read-write cycles, vibration, overheat, overvolt, overclock etc allows for a lot of damage to many peripherals even on normal PCs instead of national-infrastructural computers. – Dewi Morgan Apr 04 '19 at 20:43
1

@BillK Although it is largely software-controlled, you can't completely override it since usually a CPLD on the motherboard will manage fan control. It needs to, otherwise a complete hard lock that crashes the computer could cause it to overheat and break. But even if you somehow could totally shut off the fans (perhaps by pulsing them in a way that breaks the motors?), the CPU itself would shut off after the temperature exceeds Tj Max, and that's not something software can influence. – forest Apr 05 '19 at 05:10
@DewiMorgan When I think more about it, I'm sure it would be possible in _some_ way, since modern x86 computers are complex beasts, but I don't think there are any well-known ways. A BIOS guru would probably know more (perhaps I should ask in #libreboot or #coreboot on Freenode!). – forest Apr 05 '19 at 05:11
1

@BillK Regarding damaging monitors with evil frequencies, that actually used to be a thing for CRT monitors, and you could very easily destroy them. Even for some older LCD systems (GBA, I think?), there were ways to damage it physically through software. See https://en.wikipedia.org/wiki/Killer_poke#Game_Boy. – forest Apr 05 '19 at 05:12
@Forest: Agreed, the only attacks I've ever heard of for damaging hardware are specific per-system: there're no generic "one-size-fits-all" (or even "-many") attacks to damage hardware. Closest I can imagine would be stress-test type programs that'd expose weaknesses in flawed hardware if run over a weekend, but I'm not sure that counts as "attack" so much as "exposing the problems with cheap-ass hardware". – Dewi Morgan Apr 05 '19 at 14:13
1

Yes, I was suggesting that a targeted attack against some specific hardware could still harm it. I bet you could find some kind of software/resonance/frequency attack that could kill a video card too (Although it's more likely you could just shut down the fan, turn off the safety and heat up the card depending on implementation). Nobody seems to do anything in hardware anymore that they don't absolutely have to, the tendency to do more in software has made everything pretty vulnerable. – Bill K Apr 05 '19 at 16:47
And of course, if the attacker can attach a JTAG, all bets are off... – Dewi Morgan Apr 05 '19 at 18:10
@DewiMorgan Hm, can JTAG really damage hardware (in some way other than sending a power surge over the TAPs)? I can't think of a way it can, but it's so complex and can do so much more than just control the CPU that I wouldn't at all be surprised if it could cause physical damage via some boundary scan stuff. – forest Apr 05 '19 at 23:50
@forest: It's more that, using a JTAG, you can bypass onboard protections *against* hardware damage, in components which were not intended to be flashable by firmware updates. Not hardware protections, of course: you can't override a fuse! But you can bypass things like rate limiting, current limiting, etc. Not a realistic concern, though: with full access, it's a lot easier for any adversary to just whack the board with a hammer. – Dewi Morgan Apr 06 '19 at 17:50

score 12 · Answer 4 · answered Apr 03 '19 at 06:50

Yes, it is definitely possible.

Here is an example of a malware OS update fraudulently signed with the manufacturer's private key: https://www.theregister.co.uk/2019/03/25/asus_software_update_utility_backdoor/

According to Kaspersky Labs, about a million Asus laptops were infected by Shadowhammer, with an update that appeared to be correctly signed. It's not clear if that altered the firmware, but it certainly could have done.

score 4 · Answer 5 · answered Apr 02 '19 at 22:10

4

Your question hints at a more deep subject that is rings and permissions of code on an operating system. On MS DOS the code could do whatever it wants. If the code wanted to write all 0x00's to a hard drive it could if it wanted to send strange output to a piece of hardware it could also there was nothing stopping the user's code. On a modern OS there is a concept of rings (this is enforced by the CPU). The kernel runs on ring zero and it could do whatever it wants. The user's code on the other hand can not. It runs on something called ring 3 and it is given it's own little piece of memory and inside of that memory it can do whatever it wants but it can not directly talk to hardware. If the user's code tries to talk to hardware then the kernel immediately kills the program. This means that it is highly unlikely that a regular virus can kill hardware because it can not talk to it directly.

If the kernel is hacked then the game is basically over. The kernel can do whatever it wants and a whole host of bad things can happen such as overclocking the CPU to a point where the hardware is unstable, wiping the hard drives (filling the with zeros for example), or pretty much any other plausible attack.

answered Apr 02 '19 at 22:10

scifi6546

49
1

3

*"If the user's code tries to talk to hardware then the kernel immediately kills the program"* - Really? Can you provide a citation for that? I thought the protected instruction would simply fail and it's up to the program to deal with that reasonably or crash. – Marc.2377 Apr 02 '19 at 23:21
1

@Marc.2377 It is correct. If the user's code attempts to execute an instruction in CPL3 that requires CPL0 privileges, it will throw `#GP(0)` (general protection fault, or GPF). This causes the code to jump into the kernel to see what signal handler was set up for that event. By default, the kernel will kill the process, though it's technically possible for the process to set up a signal handler for SIGSEGV, in which case the kernel resumes execution of the process at the location of the signal handler. It's generally not a good idea though because a process is considered to be in an... – forest Apr 03 '19 at 07:20
...undefined state according to POSIX if execution resumes after a SIGSEGV has been raised that didn't come from `raise()`. It will resume execution at the failed instruction which will just run again and cause the process to lock up if the signal is ignored. So it _can_ be up to the program to deal with it, _if_ it sets up a signal handler for SIGSEGV, but there's pretty much never any situation where that would be done (though I think the Dolphin emulator catches segfaults for some sort of hacky optimization so it doesn't have to emulate some weird paging behavior and can rely on the MMU). – forest Apr 03 '19 at 07:20
See [this](https://accidentallyquadratic.tumblr.com/post/142829260822/dolphin-emulator-trampoline-generation) for a (rare) example of when it _is_ up to the program. Or just read [PoC||GTFO](https://www.alchemistowl.org/pocorgtfo/pocorgtfo06.pdf) 6:3. – forest Apr 03 '19 at 07:26

score 3 · Answer 6 · answered Apr 02 '19 at 08:13

Potentially. It would be hard to do however, as it would more than likely have to masquerade as a legit BIOS update somewhere down the line. The method to do so will change depending on your mobo but chances are it would have to involve the leaking of private or hardware keys or other secrets.

Qwertie · Answer 7 · 2019-04-04T04:44:41.883

Yes. It's hardware specific but here is one case of a user accidentally breaking their motherboard firmware from the OS level https://github.com/systemd/systemd/issues/2402

A bug in the firmware of an MSI laptop meant that clearing the efi variables caused the laptop to be unusable. Because these variables were exposed to the OS and mounted as a file, deleting every file from the OS level caused the issue which could be exploited by a virus to specifically target these variables.

user21820 · Answer 8 · 2019-04-04T11:57:00.740

There are many ways, and some of them are unsettling. For example, Computrace seems to be a permanent backdoor that can bypass not only the operating system but even the BIOS. And more generally, the Intel Management Engine has full control over your computer and can plausibly be exploited. These can modify your BIOS but do not even need to. Just in 2017, security researchers figured out how to exploit the Intel IME via USB to run unsigned code.

The point is that even if you have a completely secure operating system and you never download any insecure or malicious software, there is still a non-negligible possibility that you can be affected by a malware that bypasses all that by exploiting a security vulnerability in your hardware (even when your computer is supposedly powered off).

Lily Finley · Answer 9 · 2019-04-05T10:11:25.067

Something I haven seen here:

If the attacker gains sufficient permission to install even an official UEFI firmware, correctly signed by the system manufacturer, they can still potentially leave the computer in an un-bootable state by forcefully powering off the computer at an opportune time during the process.

The update code in modern firmwares usually tries to minimize the amount of time the computer spends in a state where a power failure will cause corruption of the firmware, and some firmwares even have a recovery mode which will activate in such a case.

However, many of these systems aren't completely bulletproof. Although they offer good protection against random power failures, a well-timed poweroff could still knock it dead if the firmware doesn't have a robust automatic recovery feature.

Also, one may not even need to attack the main system firmware. Pretty much every device in a modern PC has a firmware of some kind, and many of them can be updated via software. These devices are also often less secure. They may accept unsigned firmwares entirely, or at least be less resilient against malicious poweroffs during the update process.

If you destroy the firmware on the power controller, storage controller, storage device, video device, or input controller, the system is may become just as unusable as if you had attacked the UEFI.

Can a virus destroy the BIOS of a modern computer?

9 Answers9