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.
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 …
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.
... 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.
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.
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.
"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?
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 ...
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...
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.