Can a virus destroy the BIOS of a modern computer?





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







90















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?










share|improve this question









New contributor




user73910 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





















  • 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
    Apr 4 at 12:15











  • Comments are not for extended discussion; this conversation has been moved to chat.

    – Rory Alsop
    Apr 4 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 4 at 16:11






  • 1





    Related: security.stackexchange.com/q/13105/165253

    – forest
    2 days ago


















90















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?










share|improve this question









New contributor




user73910 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





















  • 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
    Apr 4 at 12:15











  • Comments are not for extended discussion; this conversation has been moved to chat.

    – Rory Alsop
    Apr 4 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 4 at 16:11






  • 1





    Related: security.stackexchange.com/q/13105/165253

    – forest
    2 days ago














90












90








90


12






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?










share|improve this question









New contributor




user73910 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












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






share|improve this question









New contributor




user73910 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




user73910 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited Apr 2 at 7:37







user73910













New contributor




user73910 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked Apr 2 at 7:27









user73910user73910

534125




534125




New contributor




user73910 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





user73910 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






user73910 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.













  • 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
    Apr 4 at 12:15











  • Comments are not for extended discussion; this conversation has been moved to chat.

    – Rory Alsop
    Apr 4 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 4 at 16:11






  • 1





    Related: security.stackexchange.com/q/13105/165253

    – forest
    2 days 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
    Apr 4 at 12:15











  • Comments are not for extended discussion; this conversation has been moved to chat.

    – Rory Alsop
    Apr 4 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 4 at 16:11






  • 1





    Related: security.stackexchange.com/q/13105/165253

    – forest
    2 days 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
Apr 4 at 12:15





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
Apr 4 at 12:15













Comments are not for extended discussion; this conversation has been moved to chat.

– Rory Alsop
Apr 4 at 12:42





Comments are not for extended discussion; this conversation has been moved to chat.

– Rory Alsop
Apr 4 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 4 at 16:11





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 4 at 16:11




1




1





Related: security.stackexchange.com/q/13105/165253

– forest
2 days ago





Related: security.stackexchange.com/q/13105/165253

– forest
2 days ago










9 Answers
9






active

oldest

votes


















119














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:




  1. the mainboard manufacturers manage to keep their private keys secret

  2. 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.






share|improve this answer


























  • Comments are not for extended discussion; this conversation has been moved to chat.

    – Rory Alsop
    2 days ago



















47














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).






share|improve this answer































    19














    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.






    share|improve this answer



















    • 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 2 at 23:23








    • 6





      @Marc.2377, I would not mind much if your personal information was used to order me free pizza… :-)

      – sleblanc
      Apr 3 at 3: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 3 at 7:33






    • 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 3 at 17:55






    • 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 4 at 16:00



















    11














    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.






    share|improve this answer








    New contributor




    emrys57 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.




























      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.






      share|improve this answer








      New contributor




      scifi6546 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.
















      • 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 2 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 3 at 7: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 3 at 7:20













      • See this for a (rare) example of when it is up to the program. Or just read PoC||GTFO 6:3.

        – forest
        Apr 3 at 7:26








      • 1





        @forest Thanks a lot.

        – Marc.2377
        Apr 3 at 23:52



















      3














      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.






      share|improve this answer































        3














        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.






        share|improve this answer

































          0














          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).






          share|improve this answer

































            0














            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.






            share|improve this answer
























              protected by Gilles Apr 4 at 7:27



              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?














              9 Answers
              9






              active

              oldest

              votes








              9 Answers
              9






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes









              119














              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:




              1. the mainboard manufacturers manage to keep their private keys secret

              2. 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.






              share|improve this answer


























              • Comments are not for extended discussion; this conversation has been moved to chat.

                – Rory Alsop
                2 days ago
















              119














              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:




              1. the mainboard manufacturers manage to keep their private keys secret

              2. 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.






              share|improve this answer


























              • Comments are not for extended discussion; this conversation has been moved to chat.

                – Rory Alsop
                2 days ago














              119












              119








              119







              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:




              1. the mainboard manufacturers manage to keep their private keys secret

              2. 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.






              share|improve this answer















              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:




              1. the mainboard manufacturers manage to keep their private keys secret

              2. 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.







              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited Apr 3 at 10:37

























              answered Apr 2 at 8:42









              PhilippPhilipp

              45.2k8116142




              45.2k8116142













              • Comments are not for extended discussion; this conversation has been moved to chat.

                – Rory Alsop
                2 days ago



















              • Comments are not for extended discussion; this conversation has been moved to chat.

                – Rory Alsop
                2 days ago

















              Comments are not for extended discussion; this conversation has been moved to chat.

              – Rory Alsop
              2 days ago





              Comments are not for extended discussion; this conversation has been moved to chat.

              – Rory Alsop
              2 days ago













              47














              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).






              share|improve this answer




























                47














                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).






                share|improve this answer


























                  47












                  47








                  47







                  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).






                  share|improve this answer













                  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).







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Apr 2 at 8:37









                  StephaneStephane

                  17.7k25464




                  17.7k25464























                      19














                      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.






                      share|improve this answer



















                      • 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 2 at 23:23








                      • 6





                        @Marc.2377, I would not mind much if your personal information was used to order me free pizza… :-)

                        – sleblanc
                        Apr 3 at 3: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 3 at 7:33






                      • 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 3 at 17:55






                      • 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 4 at 16:00
















                      19














                      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.






                      share|improve this answer



















                      • 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 2 at 23:23








                      • 6





                        @Marc.2377, I would not mind much if your personal information was used to order me free pizza… :-)

                        – sleblanc
                        Apr 3 at 3: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 3 at 7:33






                      • 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 3 at 17:55






                      • 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 4 at 16:00














                      19












                      19








                      19







                      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.






                      share|improve this answer













                      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.







                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered Apr 2 at 19:39









                      Dewi MorganDewi Morgan

                      1,280514




                      1,280514








                      • 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 2 at 23:23








                      • 6





                        @Marc.2377, I would not mind much if your personal information was used to order me free pizza… :-)

                        – sleblanc
                        Apr 3 at 3: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 3 at 7:33






                      • 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 3 at 17:55






                      • 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 4 at 16:00














                      • 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 2 at 23:23








                      • 6





                        @Marc.2377, I would not mind much if your personal information was used to order me free pizza… :-)

                        – sleblanc
                        Apr 3 at 3: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 3 at 7:33






                      • 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 3 at 17:55






                      • 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 4 at 16:00








                      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
                      Apr 2 at 23:23







                      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 2 at 23:23






                      6




                      6





                      @Marc.2377, I would not mind much if your personal information was used to order me free pizza… :-)

                      – sleblanc
                      Apr 3 at 3:54





                      @Marc.2377, I would not mind much if your personal information was used to order me free pizza… :-)

                      – sleblanc
                      Apr 3 at 3:54




                      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
                      Apr 3 at 7:33





                      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 3 at 7:33




                      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
                      Apr 3 at 17:55





                      @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 3 at 17:55




                      2




                      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 4 at 16:00





                      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 4 at 16:00











                      11














                      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.






                      share|improve this answer








                      New contributor




                      emrys57 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                      Check out our Code of Conduct.

























                        11














                        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.






                        share|improve this answer








                        New contributor




                        emrys57 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                        Check out our Code of Conduct.























                          11












                          11








                          11







                          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.






                          share|improve this answer








                          New contributor




                          emrys57 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                          Check out our Code of Conduct.










                          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.







                          share|improve this answer








                          New contributor




                          emrys57 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                          Check out our Code of Conduct.









                          share|improve this answer



                          share|improve this answer






                          New contributor




                          emrys57 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                          Check out our Code of Conduct.









                          answered Apr 3 at 6:50









                          emrys57emrys57

                          2112




                          2112




                          New contributor




                          emrys57 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                          Check out our Code of Conduct.





                          New contributor





                          emrys57 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                          Check out our Code of Conduct.






                          emrys57 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                          Check out our Code of Conduct.























                              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.






                              share|improve this answer








                              New contributor




                              scifi6546 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                              Check out our Code of Conduct.
















                              • 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 2 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 3 at 7: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 3 at 7:20













                              • See this for a (rare) example of when it is up to the program. Or just read PoC||GTFO 6:3.

                                – forest
                                Apr 3 at 7:26








                              • 1





                                @forest Thanks a lot.

                                – Marc.2377
                                Apr 3 at 23:52
















                              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.






                              share|improve this answer








                              New contributor




                              scifi6546 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                              Check out our Code of Conduct.
















                              • 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 2 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 3 at 7: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 3 at 7:20













                              • See this for a (rare) example of when it is up to the program. Or just read PoC||GTFO 6:3.

                                – forest
                                Apr 3 at 7:26








                              • 1





                                @forest Thanks a lot.

                                – Marc.2377
                                Apr 3 at 23:52














                              4












                              4








                              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.






                              share|improve this answer








                              New contributor




                              scifi6546 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                              Check out our Code of Conduct.










                              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.







                              share|improve this answer








                              New contributor




                              scifi6546 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                              Check out our Code of Conduct.









                              share|improve this answer



                              share|improve this answer






                              New contributor




                              scifi6546 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                              Check out our Code of Conduct.









                              answered Apr 2 at 22:10









                              scifi6546scifi6546

                              491




                              491




                              New contributor




                              scifi6546 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                              Check out our Code of Conduct.





                              New contributor





                              scifi6546 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                              Check out our Code of Conduct.






                              scifi6546 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                              Check out our Code of Conduct.








                              • 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 2 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 3 at 7: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 3 at 7:20













                              • See this for a (rare) example of when it is up to the program. Or just read PoC||GTFO 6:3.

                                – forest
                                Apr 3 at 7:26








                              • 1





                                @forest Thanks a lot.

                                – Marc.2377
                                Apr 3 at 23:52














                              • 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 2 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 3 at 7: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 3 at 7:20













                              • See this for a (rare) example of when it is up to the program. Or just read PoC||GTFO 6:3.

                                – forest
                                Apr 3 at 7:26








                              • 1





                                @forest Thanks a lot.

                                – Marc.2377
                                Apr 3 at 23:52








                              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
                              Apr 2 at 23:21





                              "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 2 at 23:21




                              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
                              Apr 3 at 7:20







                              @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 3 at 7: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 3 at 7: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 3 at 7:20















                              See this for a (rare) example of when it is up to the program. Or just read PoC||GTFO 6:3.

                              – forest
                              Apr 3 at 7:26







                              See this for a (rare) example of when it is up to the program. Or just read PoC||GTFO 6:3.

                              – forest
                              Apr 3 at 7:26






                              1




                              1





                              @forest Thanks a lot.

                              – Marc.2377
                              Apr 3 at 23:52





                              @forest Thanks a lot.

                              – Marc.2377
                              Apr 3 at 23:52











                              3














                              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.






                              share|improve this answer




























                                3














                                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.






                                share|improve this answer


























                                  3












                                  3








                                  3







                                  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.






                                  share|improve this answer













                                  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.







                                  share|improve this answer












                                  share|improve this answer



                                  share|improve this answer










                                  answered Apr 2 at 8:13









                                  520520

                                  51524




                                  51524























                                      3














                                      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.






                                      share|improve this answer






























                                        3














                                        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.






                                        share|improve this answer




























                                          3












                                          3








                                          3







                                          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.






                                          share|improve this answer















                                          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.







                                          share|improve this answer














                                          share|improve this answer



                                          share|improve this answer








                                          edited Apr 4 at 4:44

























                                          answered Apr 4 at 4:08









                                          QwertieQwertie

                                          28229




                                          28229























                                              0














                                              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).






                                              share|improve this answer






























                                                0














                                                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).






                                                share|improve this answer




























                                                  0












                                                  0








                                                  0







                                                  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).






                                                  share|improve this answer















                                                  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).







                                                  share|improve this answer














                                                  share|improve this answer



                                                  share|improve this answer








                                                  edited Apr 4 at 11:57

























                                                  answered Apr 4 at 11:45









                                                  user21820user21820

                                                  357313




                                                  357313























                                                      0














                                                      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.






                                                      share|improve this answer






























                                                        0














                                                        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.






                                                        share|improve this answer




























                                                          0












                                                          0








                                                          0







                                                          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.






                                                          share|improve this answer















                                                          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.







                                                          share|improve this answer














                                                          share|improve this answer



                                                          share|improve this answer








                                                          edited 2 days ago

























                                                          answered 2 days ago









                                                          Lily FinleyLily Finley

                                                          65145




                                                          65145

















                                                              protected by Gilles Apr 4 at 7:27



                                                              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?



                                                              Popular posts from this blog

                                                              Bruad Bilen | Luke uk diar | NawigatsjuunCommonskategorii: BruadCommonskategorii: RunstükenWikiquote: Bruad

                                                              What is the offset in a seaplane's hull?

                                                              Slayer Innehåll Historia | Stil, komposition och lyrik | Bandets betydelse och framgångar | Sidoprojekt och samarbeten | Kontroverser | Medlemmar | Utmärkelser och nomineringar | Turnéer och festivaler | Diskografi | Referenser | Externa länkar | Navigeringsmenywww.slayer.net”Metal Massacre vol. 1””Metal Massacre vol. 3””Metal Massacre Volume III””Show No Mercy””Haunting the Chapel””Live Undead””Hell Awaits””Reign in Blood””Reign in Blood””Gold & Platinum – Reign in Blood””Golden Gods Awards Winners”originalet”Kerrang! Hall Of Fame””Slayer Looks Back On 37-Year Career In New Video Series: Part Two””South of Heaven””Gold & Platinum – South of Heaven””Seasons in the Abyss””Gold & Platinum - Seasons in the Abyss””Divine Intervention””Divine Intervention - Release group by Slayer””Gold & Platinum - Divine Intervention””Live Intrusion””Undisputed Attitude””Abolish Government/Superficial Love””Release “Slatanic Slaughter: A Tribute to Slayer” by Various Artists””Diabolus in Musica””Soundtrack to the Apocalypse””God Hates Us All””Systematic - Relationships””War at the Warfield””Gold & Platinum - War at the Warfield””Soundtrack to the Apocalypse””Gold & Platinum - Still Reigning””Metallica, Slayer, Iron Mauden Among Winners At Metal Hammer Awards””Eternal Pyre””Eternal Pyre - Slayer release group””Eternal Pyre””Metal Storm Awards 2006””Kerrang! Hall Of Fame””Slayer Wins 'Best Metal' Grammy Award””Slayer Guitarist Jeff Hanneman Dies””Bullet-For My Valentine booed at Metal Hammer Golden Gods Awards””Unholy Aliance””The End Of Slayer?””Slayer: We Could Thrash Out Two More Albums If We're Fast Enough...””'The Unholy Alliance: Chapter III' UK Dates Added”originalet”Megadeth And Slayer To Co-Headline 'Canadian Carnage' Trek”originalet”World Painted Blood””Release “World Painted Blood” by Slayer””Metallica Heading To Cinemas””Slayer, Megadeth To Join Forces For 'European Carnage' Tour - Dec. 18, 2010”originalet”Slayer's Hanneman Contracts Acute Infection; Band To Bring In Guest Guitarist””Cannibal Corpse's Pat O'Brien Will Step In As Slayer's Guest Guitarist”originalet”Slayer’s Jeff Hanneman Dead at 49””Dave Lombardo Says He Made Only $67,000 In 2011 While Touring With Slayer””Slayer: We Do Not Agree With Dave Lombardo's Substance Or Timeline Of Events””Slayer Welcomes Drummer Paul Bostaph Back To The Fold””Slayer Hope to Unveil Never-Before-Heard Jeff Hanneman Material on Next Album””Slayer Debut New Song 'Implode' During Surprise Golden Gods Appearance””Release group Repentless by Slayer””Repentless - Slayer - Credits””Slayer””Metal Storm Awards 2015””Slayer - to release comic book "Repentless #1"””Slayer To Release 'Repentless' 6.66" Vinyl Box Set””BREAKING NEWS: Slayer Announce Farewell Tour””Slayer Recruit Lamb of God, Anthrax, Behemoth + Testament for Final Tour””Slayer lägger ner efter 37 år””Slayer Announces Second North American Leg Of 'Final' Tour””Final World Tour””Slayer Announces Final European Tour With Lamb of God, Anthrax And Obituary””Slayer To Tour Europe With Lamb of God, Anthrax And Obituary””Slayer To Play 'Last French Show Ever' At Next Year's Hellfst””Slayer's Final World Tour Will Extend Into 2019””Death Angel's Rob Cavestany On Slayer's 'Farewell' Tour: 'Some Of Us Could See This Coming'””Testament Has No Plans To Retire Anytime Soon, Says Chuck Billy””Anthrax's Scott Ian On Slayer's 'Farewell' Tour Plans: 'I Was Surprised And I Wasn't Surprised'””Slayer””Slayer's Morbid Schlock””Review/Rock; For Slayer, the Mania Is the Message””Slayer - Biography””Slayer - Reign In Blood”originalet”Dave Lombardo””An exclusive oral history of Slayer”originalet”Exclusive! Interview With Slayer Guitarist Jeff Hanneman”originalet”Thinking Out Loud: Slayer's Kerry King on hair metal, Satan and being polite””Slayer Lyrics””Slayer - Biography””Most influential artists for extreme metal music””Slayer - Reign in Blood””Slayer guitarist Jeff Hanneman dies aged 49””Slatanic Slaughter: A Tribute to Slayer””Gateway to Hell: A Tribute to Slayer””Covered In Blood””Slayer: The Origins of Thrash in San Francisco, CA.””Why They Rule - #6 Slayer”originalet”Guitar World's 100 Greatest Heavy Metal Guitarists Of All Time”originalet”The fans have spoken: Slayer comes out on top in readers' polls”originalet”Tribute to Jeff Hanneman (1964-2013)””Lamb Of God Frontman: We Sound Like A Slayer Rip-Off””BEHEMOTH Frontman Pays Tribute To SLAYER's JEFF HANNEMAN””Slayer, Hatebreed Doing Double Duty On This Year's Ozzfest””System of a Down””Lacuna Coil’s Andrea Ferro Talks Influences, Skateboarding, Band Origins + More””Slayer - Reign in Blood””Into The Lungs of Hell””Slayer rules - en utställning om fans””Slayer and Their Fans Slashed Through a No-Holds-Barred Night at Gas Monkey””Home””Slayer””Gold & Platinum - The Big 4 Live from Sofia, Bulgaria””Exclusive! Interview With Slayer Guitarist Kerry King””2008-02-23: Wiltern, Los Angeles, CA, USA””Slayer's Kerry King To Perform With Megadeth Tonight! - Oct. 21, 2010”originalet”Dave Lombardo - Biography”Slayer Case DismissedArkiveradUltimate Classic Rock: Slayer guitarist Jeff Hanneman dead at 49.”Slayer: "We could never do any thing like Some Kind Of Monster..."””Cannibal Corpse'S Pat O'Brien Will Step In As Slayer'S Guest Guitarist | The Official Slayer Site”originalet”Slayer Wins 'Best Metal' Grammy Award””Slayer Guitarist Jeff Hanneman Dies””Kerrang! Awards 2006 Blog: Kerrang! Hall Of Fame””Kerrang! Awards 2013: Kerrang! Legend”originalet”Metallica, Slayer, Iron Maien Among Winners At Metal Hammer Awards””Metal Hammer Golden Gods Awards””Bullet For My Valentine Booed At Metal Hammer Golden Gods Awards””Metal Storm Awards 2006””Metal Storm Awards 2015””Slayer's Concert History””Slayer - Relationships””Slayer - Releases”Slayers officiella webbplatsSlayer på MusicBrainzOfficiell webbplatsSlayerSlayerr1373445760000 0001 1540 47353068615-5086262726cb13906545x(data)6033143kn20030215029