[Cryptography] trojans in the firmware

Mirimir mirimir at riseup.net
Wed Feb 18 23:17:10 PST 2015

On 02/18/2015 09:13 PM, grarpamp wrote:
> On Wed, Feb 18, 2015 at 8:57 PM, Henry Baker <hbaker1 at pipeline.com> wrote:
>> At 03:12 PM 2/18/2015, grarpamp wrote:
>>> 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.
>> ????  If the disk drive or flash drive firmware has already
>> been compromised, none of this will work, because the firmware
>> simply waits for the appropriate "legitimate" read & write
>> commands, and does its thing.
> Obviously. This is only meant to help protect clean
> systems, or prevent subsequent malicious commands if
> they happen to go through a user to kernel path that has
> for some reason not yet been compromised (say through
> the usual /dev to driver to hardware path).
>> BTW, what happens with "emulated" disks -- e.g., .vdi files --
>> in vm's ?  Presumably these emulated disks have no firmware to
>> update, so any attempt would either be ignored or crash the
>> system.
> Depends on how the vm is coded. My guess is vm's that emulate
> say disk devices, munge those opcodes too. Yes, looking at how
> virtualbox and even lightweight instances like jails code/handle it
> could be useful. Try it and see :)

In the VirtualBox manual, I see:

| Starting with version 1.4, as an alternative to using virtual
| disk images (as described in detail in Chapter 5, Virtual
| storage), VirtualBox can also present either entire physical
| hard disks or selected partitions thereof as virtual disks
| to virtual machines.
| With VirtualBox, this type of access is called "raw hard
| disk access"; it allows a guest operating system to access
| its virtual hard disk without going through the host OS
| file system. ...


Given that, I'm assuming that when using VDIs, the host OS doesn't allow
VMs to directly access physical disks. And I don't see how a VM could
reconfigure itself for raw hard disk access to the host disk, because
doing so would such access to its own config. But if anyone can manage
it, the NSA arguably can.

> In all cases, having the logging capability for non production
> opcodes without having to postfilter them out of some
> debugging stream would be nice. Obviously again caveat
> parts of the system that have not been compromised,
> and defense in depth.

More information about the cypherpunks mailing list