back to article VirusTotal bashes bad BIOSes with forensic firmware fossicker

VirusTotal can now analyse firmware for known malware, prying inside almost-hard-coded code for hidden executables. The service allows users to search for low-level infections in embedded devices and BIOS which could represent the handiwork of sophisticated malware or well-resourced or dedicated attackers. Security engineer …

  1. Pascal Monett Silver badge

    Impressive

    I hope this actually works. I'll be checking it out and, if it seems workable for me, I'll include a check in my regular scans.

  2. Duncan Macdonald

    Intel Management Engine ?

    Can it analyse the firmware for the Intel Management Engine in modern Intel chips?

    Any nasties placed there (possibly signed by Intel at the request of NSA) are almost immune to detection on a running system.

    1. Anonymous Coward
      Pirate

      Re: Intel Management Engine ?

      Came to say the same. I very much doubt it.

      Probably snake oil.

    2. A Non e-mouse Silver badge
      Unhappy

      Re: Intel Management Engine ?

      According to this FAQ posting on the Libreboot FAQ, with all of Intel's latest toys on the CPU, you can't guarantee anything.

      It seems that a modern CPU is no longer "just" a CPU, but a full-blown computer in itself.

      1. Down not across

        Re: Intel Management Engine ?

        According to this FAQ posting on the Libreboot FAQ, with all of Intel's latest toys on the CPU, you can't guarantee anything.

        Hmm...and from that FAQ:

        Its boot program, stored on the internal ROM, loads a firmware "manifest" from the PC's SPI flash chip. This manifest is signed with a strong cryptographic key, which differs between versions of the ME firmware. If the manifest isn't signed by a specific Intel key, the boot ROM won't load and execute the firmware and the ME processor core will be halted.

        Makes one wonder if you could intentionally place incorrectly signed placeholder in flash to effectively disable the ME core. Ah..looks like not..

        Before version 6.0 (that is, on systems from 2008/2009 and earlier), the ME can be disabled by setting a couple of values in the SPI flash memory. The ME firmware can then be removed entirely from the flash memory space. libreboot does this on the Intel 4 Series systems that it supports, such as the Libreboot X200 and Libreboot T400. ME firmware versions 6.0 and later, which are found on all systems with an Intel Core i3/i5/i7 CPU and a PCH, include "ME Ingition" firmware that performs some hardware initialization and power management. If the ME's boot ROM does not find in the SPI flash memory an ME firmware manifest with a valid Intel signature, the whole PC will shut down after 30 minutes.

        That is seriously evil. And AMD is not really any better, reading the FAQ further.

    3. Anonymous Coward
      Anonymous Coward

      Re: Intel Management Engine ?

      http://c2.com/cgi/wiki?TheKenThompsonHack

    4. Christian Berger

      Virus scanners don't analyze software...

      ... particularly since that's been proven mathematically to be impossible in 1953 by Henry Gordon Rice.

      What virus scanners do is to try do unpack containers and then search for byte strings. That's why they only find malware that was explicitly put into the databases they use. If you "hand craft" some malware it will simply not be detected.

      Of course the sensible way to do security is to simplify everything down to a level you have a chance to understand. Essentially you'd have a tiny "compiler/interpreter" which is small enough to be understood in binary (Forth can do that for example) from which you bootstrap your system by running source code from the disk. When you keep it all small enough, it probably won't even take longer to boot than our current systems.

      1. Anonymous Coward
        Anonymous Coward

        Re: Virus scanners don't analyze software...

        Re: Virus scanners don't analyze software.

        Sun computers used to boot to a Forth to bring up the rest of the system as part of the bios.

        It used to be possible to use it to debug startup hardware problems. I used to know the guy who wrote it

        PDF]OpenBoot Command Reference Manual - Oracle ...

        https://docs.oracle.com/cd/E19457.../801-7042.pdf

        Oracle Corporation

        Aug 10, 1994 - or registered trademarks of Sun Microsystems, Inc. UNIX and OPEN LOOK are ...... describes the commands of the OpenBoot Forth Interpreter.

        1. Christian Berger

          OpenFirmware

          Yes, that was OpenFirmware. It could do all the things UEFI can and more... but at a thousand times less code.

  3. Flocke Kroes Silver badge

    Catch 22

    There was a time when the BIOS was stored in a chip in a socket. You could pull the chip out, put it in your EEPROM programmer and compare it to a known good image. Back then EEPROMs were so small that you could not hide anything complicated inside them.

    These days, you can fit a few operating system kernels into the boot flash chip. Enough space to hide the real contents and present a white-listed image to high level software. The chip is soldered down, so your only real hope of finding out what is actually inside is via JTAG.

    If only the CPU had enough on-chip ROM to boot from micro-SD, and did not require over a GB of secret binary blobs to do anything useful.

    1. Anonymous Coward
      Anonymous Coward

      Re: Catch 22

      "The chip is soldered down, so your only real hope of finding out what is actually inside is via JTAG"

      On some modenr ASUS boards (Z87 & Z97 Pro, I think), it's a separate chip, so if it gets corrupted, you can just pull it out and send it to them for replacement.

      1. allthecoolshortnamesweretaken

        Re: Catch 22

        "On some modern ASUS boards [...] it's a separate chip, so if it gets corrupted, you can just pull it out and send it to them for replacement."

        If I understand this sub-thread right, we are discussing BIOS/BIOS chips that are 'tainted at the source', so to speak - so what good would replacing it with a new chip from the same source do?

    2. Anonymous Coward
      Anonymous Coward

      Re: Catch 22

      "If only the CPU had enough on-chip ROM to boot from micro-SD"

      Absolutely.

      Would something like this help:

      http://raspberrypi.stackexchange.com/questions/10489/how-does-raspberry-pi-boot

  4. Simon Crowe

    So what downloads your BIOS

    If i understand it, there are BIOS functions to access your BIOS, so whats to stop your bad bios giving you a good bios when you request to download it (AKA Stuxnet when validating the motor control software).

    Once, the bad guys are in the BIOS (or Disk, or baseboard controller, or NIC) you are probably never going to get rid of them ...

    As others have alluded to, having a SD card with the firmware downloaded directly from the manufacturer may help, but that really will not stop the three letter agencies forcing manufacturers putting their code into the device firmware from the get go ...

    Don't even get me started on the concept of management engine ...

    1. Anonymous Coward
      Anonymous Coward

      Re: So what downloads your BIOS

      If your tinfoil hat gets any bigger you wont be able to see out!

  5. iMap

    My/ Our systems work, this could bork them forcing a purchase of new replacement devices.

    Stay clear of unfounded claims I say or use at your own pearl.

  6. Charles 9

    Sounds like what's needed is some kind of fallback, built directly into the hardware so it can never be overridden, that allows you to reflash a firmware from some other source. Needs to be mandatory as a security measure.

    1. allthecoolshortnamesweretaken

      Off the top of my head I can see at least two or three problems with that.

      1 how would you be able to vet the 'unoverridable hardware fallback' to make sure it really can't be overridden (for instance by bespoke code from the same source that designed/built the hardware)

      2 if the firmware is reflashed from some other source, how can can you make sure the 'other source' is clean? For all you know you'll just be replacing some dodgy bits with some other dodgy bits. And you probably won't be able to able to write your own version of the firmware because you don't have all the specs of the kit it's supposed to run on

      3 technically, if the 'unoverridable hardware fallback' allows me to reflash firmware - doesn't that mean it's an override in itself?

      Bootnote: way back when, EEPROMS and dip switches on the mainboard seemed like a hassle...

      1. Charles 9

        The point is that the option will always remain open, which is something the EEPROMers may not have seen as necessary in a less-security-conscious world. Sure, there's the risk of flashing dodgy bits, but the point is that you don't end up like with those MacBooks: locked out. Worst comes to worst, you can always RE-flash. As for scenario #1, you're talking about someone able to subvert at the hardware level, meaning probably state-level adversaries. That's pretty much "bend over because you're screwed" territory because that's subversion at the physical level: the Nineteen Eighty-Four Panopticon. At that point, you're in DTA Mode because nothing is safe anymore.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like