[Cryptography] trojans in the firmware

grarpamp grarpamp at gmail.com
Wed Feb 18 18:12:07 EST 2015


On Wed, Feb 18, 2015 at 5:16 PM, Tom Mitchell <mitch at niftyegg.com> wrote:
> The critical stage is the boot  ROM (BIOS) and the boot device.
> Once Linux has booted a lot is possible but too much has already taken
> place.
> A BIOS that allows booting from a Flash memory card must be trusted.
>
> Virtual machines may help or hinder.
>
> The VM is sitting where the man in the middle wants to be and if it wants
> can protect or expose
> the OSs that it hosts.   A VM can protect a hard drive from being infected
> by blocking vendor
> codes that might try to update or corrupt modern disks of boot flash memory.

Afaik, all vm's today simply pass through all drive commands.

It seems a move all the BSD's and Linux could make today,
without waiting on untrustable hardware vendors to roll out signature
verification in hardware, is to simply kernel block all commands
unnecessary to actual production use of the disk. Permit only
from a list of READ, WRITE, ERASE, INQ, TUR, RST, and so on.
Thus every other command component, including firmware update,
vendor specific, and binary fuzzing, gets dropped and logged.

It could be done as a securelevel, or compiled in.

It's definitely not bulletproof, but it does force adversaries
to add that much more exploit code and effort to
get root and go around the driver interface to access
the hardware directly. Defense in depth.

Similar tactics could be applied to other areas where
firmware and vendor/fuzzable opcodes are involved...
usb, bios and cpu.


More information about the cryptography mailing list