Can a virus destroy the BIOS of a modern computer?is computrace a permanent backdoor?BIOS upgrade only with PGP-signature / encrypting the whole BIOSProtecting the BIOS from malwareUnlock a computer bios?Can Restarting An Infected Computer Make It Worse?Can HDD without OS contain active virusCan BIOS malware be installed from OS?Feasibility of infecting notebook BIOS with virus?Can BIOS/UEFI change OS code?Explain how a BIOS/UEFI infection may compromise the security of the Operating SystemIs knowing the BIOS password of help in hacking a computer *remotely*?
How can I tell someone that I want to be his or her friend?
How could indestructible materials be used in power generation?
Anagram holiday
Forgetting the musical notes while performing in concert
Took a trip to a parallel universe, need help deciphering
Will google still index a page if I use a $_SESSION variable?
Intersection of two sorted vectors in C++
How much of data wrangling is a data scientist's job?
A reference to a well-known characterization of scattered compact spaces
Python: return float 1.0 as int 1 but float 1.5 as float 1.5
Can one be a co-translator of a book, if he does not know the language that the book is translated into?
Alternative to sending password over mail?
When a company launches a new product do they "come out" with a new product or do they "come up" with a new product?
Were any external disk drives stacked vertically?
Is "remove commented out code" correct English?
Doing something right before you need it - expression for this?
How do I write bicross product symbols in latex?
How to take photos in burst mode, without vibration?
Is it inappropriate for a student to attend their mentor's dissertation defense?
Why is it a bad idea to hire a hitman to eliminate most corrupt politicians?
Today is the Center
What do you call someone who asks many questions?
Is it possible to run Internet Explorer on OS X El Capitan?
What is the word for reserving something for yourself before others do?
Can a virus destroy the BIOS of a modern computer?
is computrace a permanent backdoor?BIOS upgrade only with PGP-signature / encrypting the whole BIOSProtecting the BIOS from malwareUnlock a computer bios?Can Restarting An Infected Computer Make It Worse?Can HDD without OS contain active virusCan BIOS malware be installed from OS?Feasibility of infecting notebook BIOS with virus?Can BIOS/UEFI change OS code?Explain how a BIOS/UEFI infection may compromise the security of the Operating SystemIs knowing the BIOS password of help in hacking a computer *remotely*?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
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?
malware virus operating-systems bios
New contributor
add a comment |
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?
malware virus operating-systems bios
New contributor
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... welivesecurity.com/wp-content/uploads/2018/09/ESET-LoJax.pdf
– Hugo
14 hours ago
Comments are not for extended discussion; this conversation has been moved to chat.
– Rory Alsop♦
13 hours ago
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
10 hours ago
add a comment |
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?
malware virus operating-systems bios
New contributor
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?
malware virus operating-systems bios
malware virus operating-systems bios
New contributor
New contributor
edited 2 days ago
user73910
New contributor
asked 2 days ago
user73910user73910
526125
526125
New contributor
New contributor
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... welivesecurity.com/wp-content/uploads/2018/09/ESET-LoJax.pdf
– Hugo
14 hours ago
Comments are not for extended discussion; this conversation has been moved to chat.
– Rory Alsop♦
13 hours ago
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
10 hours ago
add a comment |
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... welivesecurity.com/wp-content/uploads/2018/09/ESET-LoJax.pdf
– Hugo
14 hours ago
Comments are not for extended discussion; this conversation has been moved to chat.
– Rory Alsop♦
13 hours ago
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
10 hours ago
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... welivesecurity.com/wp-content/uploads/2018/09/ESET-LoJax.pdf
– Hugo
14 hours ago
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... welivesecurity.com/wp-content/uploads/2018/09/ESET-LoJax.pdf
– Hugo
14 hours ago
Comments are not for extended discussion; this conversation has been moved to chat.
– Rory Alsop♦
13 hours ago
Comments are not for extended discussion; this conversation has been moved to chat.
– Rory Alsop♦
13 hours ago
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
10 hours ago
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
10 hours ago
add a comment |
8 Answers
8
active
oldest
votes
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.
24
1) UEFI is a subtype of BIOS. 2) If an attacker can get physical access to your computer, they don't need to be able to sign their BIOS malware; they can simply desolder the chip from the motherboard and forcibly overwrite the data contained therein.
– Sean
2 days ago
23
@mbrig - It was the opposite. Systemd mounted some EFI variables as R/W by default, and thenrm -rf / --no-preserve-root
would clobber them, which bricked some poorly implemented motherboards. In predictable SystemD fashion, they then handled the issue extremely badly.
– Fake Name
2 days ago
6
@Sean UEFI programs and BIOS are both types of firmware that fulfil the same purposes, but UEFI is not BIOS or subtype of BIOS. While it's common to refer to the UEFI firmware as a "UEFI BIOS" it is not technically correct, and manufactures ship fallback BIOS firmware along with UEFI compliant firmware all the time.
– ZombieTfk
yesterday
5
Surely it's relevant that someone managed to sign BIOS/UEFI firmware with a manufacturers key and distribute it through live update: threatpost.com/asus-pc-backdoors-shadowhammer/143129
– JimmyJames
yesterday
4
@Rodney the CPU can't force the firmware to do anything, it can only interact with it through defined channels, no matter what privilege level the malware is running at. Just like even kernel level malware can't send a microcode update to an intel CPU without a valid signing key.
– mbrig
yesterday
|
show 11 more comments
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).
add a comment |
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.
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
2 days ago
6
@Marc.2377, I would not mind much if your personal information was used to order me free pizza… :-)
– sleblanc
yesterday
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
yesterday
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
yesterday
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
yesterday
|
show 4 more comments
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.
New contributor
add a comment |
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.
New contributor
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
2 days ago
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
yesterday
...undefined state according to POSIX if execution resumes after a SIGSEGV has been raised that didn't come fromraise()
. 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
yesterday
See this for a (rare) example of when it is up to the program. Or just read PoC||GTFO 6:3.
– forest
yesterday
1
@forest Thanks a lot.
– Marc.2377
yesterday
add a comment |
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.
add a comment |
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.
add a comment |
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).
add a comment |
protected by Gilles 18 hours ago
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
8 Answers
8
active
oldest
votes
8 Answers
8
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
24
1) UEFI is a subtype of BIOS. 2) If an attacker can get physical access to your computer, they don't need to be able to sign their BIOS malware; they can simply desolder the chip from the motherboard and forcibly overwrite the data contained therein.
– Sean
2 days ago
23
@mbrig - It was the opposite. Systemd mounted some EFI variables as R/W by default, and thenrm -rf / --no-preserve-root
would clobber them, which bricked some poorly implemented motherboards. In predictable SystemD fashion, they then handled the issue extremely badly.
– Fake Name
2 days ago
6
@Sean UEFI programs and BIOS are both types of firmware that fulfil the same purposes, but UEFI is not BIOS or subtype of BIOS. While it's common to refer to the UEFI firmware as a "UEFI BIOS" it is not technically correct, and manufactures ship fallback BIOS firmware along with UEFI compliant firmware all the time.
– ZombieTfk
yesterday
5
Surely it's relevant that someone managed to sign BIOS/UEFI firmware with a manufacturers key and distribute it through live update: threatpost.com/asus-pc-backdoors-shadowhammer/143129
– JimmyJames
yesterday
4
@Rodney the CPU can't force the firmware to do anything, it can only interact with it through defined channels, no matter what privilege level the malware is running at. Just like even kernel level malware can't send a microcode update to an intel CPU without a valid signing key.
– mbrig
yesterday
|
show 11 more comments
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.
24
1) UEFI is a subtype of BIOS. 2) If an attacker can get physical access to your computer, they don't need to be able to sign their BIOS malware; they can simply desolder the chip from the motherboard and forcibly overwrite the data contained therein.
– Sean
2 days ago
23
@mbrig - It was the opposite. Systemd mounted some EFI variables as R/W by default, and thenrm -rf / --no-preserve-root
would clobber them, which bricked some poorly implemented motherboards. In predictable SystemD fashion, they then handled the issue extremely badly.
– Fake Name
2 days ago
6
@Sean UEFI programs and BIOS are both types of firmware that fulfil the same purposes, but UEFI is not BIOS or subtype of BIOS. While it's common to refer to the UEFI firmware as a "UEFI BIOS" it is not technically correct, and manufactures ship fallback BIOS firmware along with UEFI compliant firmware all the time.
– ZombieTfk
yesterday
5
Surely it's relevant that someone managed to sign BIOS/UEFI firmware with a manufacturers key and distribute it through live update: threatpost.com/asus-pc-backdoors-shadowhammer/143129
– JimmyJames
yesterday
4
@Rodney the CPU can't force the firmware to do anything, it can only interact with it through defined channels, no matter what privilege level the malware is running at. Just like even kernel level malware can't send a microcode update to an intel CPU without a valid signing key.
– mbrig
yesterday
|
show 11 more comments
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.
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.
edited yesterday
answered 2 days ago
PhilippPhilipp
45.1k8116142
45.1k8116142
24
1) UEFI is a subtype of BIOS. 2) If an attacker can get physical access to your computer, they don't need to be able to sign their BIOS malware; they can simply desolder the chip from the motherboard and forcibly overwrite the data contained therein.
– Sean
2 days ago
23
@mbrig - It was the opposite. Systemd mounted some EFI variables as R/W by default, and thenrm -rf / --no-preserve-root
would clobber them, which bricked some poorly implemented motherboards. In predictable SystemD fashion, they then handled the issue extremely badly.
– Fake Name
2 days ago
6
@Sean UEFI programs and BIOS are both types of firmware that fulfil the same purposes, but UEFI is not BIOS or subtype of BIOS. While it's common to refer to the UEFI firmware as a "UEFI BIOS" it is not technically correct, and manufactures ship fallback BIOS firmware along with UEFI compliant firmware all the time.
– ZombieTfk
yesterday
5
Surely it's relevant that someone managed to sign BIOS/UEFI firmware with a manufacturers key and distribute it through live update: threatpost.com/asus-pc-backdoors-shadowhammer/143129
– JimmyJames
yesterday
4
@Rodney the CPU can't force the firmware to do anything, it can only interact with it through defined channels, no matter what privilege level the malware is running at. Just like even kernel level malware can't send a microcode update to an intel CPU without a valid signing key.
– mbrig
yesterday
|
show 11 more comments
24
1) UEFI is a subtype of BIOS. 2) If an attacker can get physical access to your computer, they don't need to be able to sign their BIOS malware; they can simply desolder the chip from the motherboard and forcibly overwrite the data contained therein.
– Sean
2 days ago
23
@mbrig - It was the opposite. Systemd mounted some EFI variables as R/W by default, and thenrm -rf / --no-preserve-root
would clobber them, which bricked some poorly implemented motherboards. In predictable SystemD fashion, they then handled the issue extremely badly.
– Fake Name
2 days ago
6
@Sean UEFI programs and BIOS are both types of firmware that fulfil the same purposes, but UEFI is not BIOS or subtype of BIOS. While it's common to refer to the UEFI firmware as a "UEFI BIOS" it is not technically correct, and manufactures ship fallback BIOS firmware along with UEFI compliant firmware all the time.
– ZombieTfk
yesterday
5
Surely it's relevant that someone managed to sign BIOS/UEFI firmware with a manufacturers key and distribute it through live update: threatpost.com/asus-pc-backdoors-shadowhammer/143129
– JimmyJames
yesterday
4
@Rodney the CPU can't force the firmware to do anything, it can only interact with it through defined channels, no matter what privilege level the malware is running at. Just like even kernel level malware can't send a microcode update to an intel CPU without a valid signing key.
– mbrig
yesterday
24
24
1) UEFI is a subtype of BIOS. 2) If an attacker can get physical access to your computer, they don't need to be able to sign their BIOS malware; they can simply desolder the chip from the motherboard and forcibly overwrite the data contained therein.
– Sean
2 days ago
1) UEFI is a subtype of BIOS. 2) If an attacker can get physical access to your computer, they don't need to be able to sign their BIOS malware; they can simply desolder the chip from the motherboard and forcibly overwrite the data contained therein.
– Sean
2 days ago
23
23
@mbrig - It was the opposite. Systemd mounted some EFI variables as R/W by default, and then
rm -rf / --no-preserve-root
would clobber them, which bricked some poorly implemented motherboards. In predictable SystemD fashion, they then handled the issue extremely badly.– Fake Name
2 days ago
@mbrig - It was the opposite. Systemd mounted some EFI variables as R/W by default, and then
rm -rf / --no-preserve-root
would clobber them, which bricked some poorly implemented motherboards. In predictable SystemD fashion, they then handled the issue extremely badly.– Fake Name
2 days ago
6
6
@Sean UEFI programs and BIOS are both types of firmware that fulfil the same purposes, but UEFI is not BIOS or subtype of BIOS. While it's common to refer to the UEFI firmware as a "UEFI BIOS" it is not technically correct, and manufactures ship fallback BIOS firmware along with UEFI compliant firmware all the time.
– ZombieTfk
yesterday
@Sean UEFI programs and BIOS are both types of firmware that fulfil the same purposes, but UEFI is not BIOS or subtype of BIOS. While it's common to refer to the UEFI firmware as a "UEFI BIOS" it is not technically correct, and manufactures ship fallback BIOS firmware along with UEFI compliant firmware all the time.
– ZombieTfk
yesterday
5
5
Surely it's relevant that someone managed to sign BIOS/UEFI firmware with a manufacturers key and distribute it through live update: threatpost.com/asus-pc-backdoors-shadowhammer/143129
– JimmyJames
yesterday
Surely it's relevant that someone managed to sign BIOS/UEFI firmware with a manufacturers key and distribute it through live update: threatpost.com/asus-pc-backdoors-shadowhammer/143129
– JimmyJames
yesterday
4
4
@Rodney the CPU can't force the firmware to do anything, it can only interact with it through defined channels, no matter what privilege level the malware is running at. Just like even kernel level malware can't send a microcode update to an intel CPU without a valid signing key.
– mbrig
yesterday
@Rodney the CPU can't force the firmware to do anything, it can only interact with it through defined channels, no matter what privilege level the malware is running at. Just like even kernel level malware can't send a microcode update to an intel CPU without a valid signing key.
– mbrig
yesterday
|
show 11 more comments
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).
add a comment |
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).
add a comment |
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).
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).
answered 2 days ago
StephaneStephane
17.7k25464
17.7k25464
add a comment |
add a comment |
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.
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
2 days ago
6
@Marc.2377, I would not mind much if your personal information was used to order me free pizza… :-)
– sleblanc
yesterday
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
yesterday
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
yesterday
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
yesterday
|
show 4 more comments
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.
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
2 days ago
6
@Marc.2377, I would not mind much if your personal information was used to order me free pizza… :-)
– sleblanc
yesterday
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
yesterday
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
yesterday
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
yesterday
|
show 4 more comments
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.
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 2 days ago
Dewi MorganDewi Morgan
1,260514
1,260514
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
2 days ago
6
@Marc.2377, I would not mind much if your personal information was used to order me free pizza… :-)
– sleblanc
yesterday
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
yesterday
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
yesterday
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
yesterday
|
show 4 more comments
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
2 days ago
6
@Marc.2377, I would not mind much if your personal information was used to order me free pizza… :-)
– sleblanc
yesterday
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
yesterday
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
yesterday
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
yesterday
2
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
2 days ago
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
2 days ago
6
6
@Marc.2377, I would not mind much if your personal information was used to order me free pizza… :-)
– sleblanc
yesterday
@Marc.2377, I would not mind much if your personal information was used to order me free pizza… :-)
– sleblanc
yesterday
2
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
yesterday
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
yesterday
1
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
yesterday
@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
yesterday
2
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
yesterday
@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
yesterday
|
show 4 more comments
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.
New contributor
add a comment |
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.
New contributor
add a comment |
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.
New contributor
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.
New contributor
New contributor
answered yesterday
emrys57emrys57
2112
2112
New contributor
New contributor
add a comment |
add a comment |
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.
New contributor
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
2 days ago
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
yesterday
...undefined state according to POSIX if execution resumes after a SIGSEGV has been raised that didn't come fromraise()
. 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
yesterday
See this for a (rare) example of when it is up to the program. Or just read PoC||GTFO 6:3.
– forest
yesterday
1
@forest Thanks a lot.
– Marc.2377
yesterday
add a comment |
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.
New contributor
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
2 days ago
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
yesterday
...undefined state according to POSIX if execution resumes after a SIGSEGV has been raised that didn't come fromraise()
. 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
yesterday
See this for a (rare) example of when it is up to the program. Or just read PoC||GTFO 6:3.
– forest
yesterday
1
@forest Thanks a lot.
– Marc.2377
yesterday
add a comment |
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.
New contributor
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.
New contributor
New contributor
answered 2 days ago
scifi6546scifi6546
491
491
New contributor
New contributor
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
2 days ago
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
yesterday
...undefined state according to POSIX if execution resumes after a SIGSEGV has been raised that didn't come fromraise()
. 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
yesterday
See this for a (rare) example of when it is up to the program. Or just read PoC||GTFO 6:3.
– forest
yesterday
1
@forest Thanks a lot.
– Marc.2377
yesterday
add a comment |
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
2 days ago
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
yesterday
...undefined state according to POSIX if execution resumes after a SIGSEGV has been raised that didn't come fromraise()
. 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
yesterday
See this for a (rare) example of when it is up to the program. Or just read PoC||GTFO 6:3.
– forest
yesterday
1
@forest Thanks a lot.
– Marc.2377
yesterday
3
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
2 days ago
"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
2 days ago
1
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
yesterday
@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
yesterday
...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
yesterday
...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
yesterday
See this for a (rare) example of when it is up to the program. Or just read PoC||GTFO 6:3.
– forest
yesterday
See this for a (rare) example of when it is up to the program. Or just read PoC||GTFO 6:3.
– forest
yesterday
1
1
@forest Thanks a lot.
– Marc.2377
yesterday
@forest Thanks a lot.
– Marc.2377
yesterday
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered 2 days ago
520520
50724
50724
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
edited 21 hours ago
answered 22 hours ago
QwertieQwertie
28229
28229
add a comment |
add a comment |
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).
add a comment |
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).
add a comment |
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).
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).
edited 14 hours ago
answered 14 hours ago
user21820user21820
357313
357313
add a comment |
add a comment |
protected by Gilles 18 hours ago
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
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... welivesecurity.com/wp-content/uploads/2018/09/ESET-LoJax.pdf
– Hugo
14 hours ago
Comments are not for extended discussion; this conversation has been moved to chat.
– Rory Alsop♦
13 hours ago
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
10 hours ago