freebsd security - Feb 2015 - [Cryptography] trojans in the firmware

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.

At 03:12 PM 2/18/2015, grarpamp wrote:
>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.
????  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.

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.

On 2/18/2015 5:12 PM, grarpamp wrote:
> 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.
The basic problem with this is that it makes two assumptions, both of 
which are dangerous.

1. The BIOS (which reads the boot sector) has not been compromised. If 
it has been you're hosed.  Most if not all BIOS chips are 
field-programmable today which is both good and bad.  It's good when you 
want to swap in a newer stepping CPU that wasn't formerly supported, 
it's bad when someone comes along and tampers with it. Hardware 
protection (e.g. a physical write-enable jumper on the board) would 
largely address this in terms of FIELD tampering (although not at the 
OEM level) but I know of nobody doing that right now.  All my SuperMicro 
systems, for example, require nothing physical (e.g. a jumper to be 
installed) to enable a BIOS update.

2. Once the drive code has been tampered with you're in trouble because 
it is trivial for the drive to detect that the boot sector is being read 
and, if it is, to return something other than the real (unmolested) boot 
sector.  That can then retrieve more corrupted things and now you're cooked.

I like barrier-protecting the I/O subsystem when running, but then again 
how many of these attacks are going to be loaded into your machine 
through a _*running*_ modern BSD-style system?  I suspect the answer is 
"few" and a false sense of security is worse than none at all.

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2711 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.freebsd.org/pipermail/freebsd-security/attachments/20150219/c2db6c5c/attachment.bin>