> One thing the articles about this problem keep saying and which doesn't
> make complete sense is that "this infection is immune to removal".
> There is a method to get the infection into spare sectors and into
> firmware, which seems to me to mean that there *is* a way to see those
> raw sectors and/or firmware in a such a way as to a) see what's there;
> and b) remodify the firmware.
> 
> It might be that if you are dependent on the firmware to inspect or
> replace the firmware, then the infected firmware could just lie to you
> in order to hide itself.  In which case, these devices really need to
> have some offline way of inspecting their flash sufficient to generate
> dumps and checksums to verify they are running what you think they are
> running.

Yes, that very well may be the case.  Much like kernel-level root kits
that return a clean version of an infected binary upon read(), but run
a different version when and exec system call is run.

Besides, even if a BIOS read did return the infected version, we don't
have any off-the-shelf tools to test for the infection.


> What tools currently exist on linux to inspect the hard disk firmware?
> I recall updating some hard disk firmware (several years ago), but
> perhaps using a vendor supplied freedos-based software kit.

I don't know of any, but I haven't looked.  Similar to BadUSB
research, you'd probably have to reverse engineer the vendor-supplied
HD BIOS update software to figure out how they do it.  It's probably
just a matter of sending a vendor-specific "magic word" over to the
HD.  I know there's been interest in creating open source system
BIOSes, but not sure about HDs.

IMO, HD vendors shouldn't provide a way to update their firmwares over
ATA, unless it involves some serious downtime.  For instance, they
could require that the flashing can only occur after being authorized
directly by the Firmware during a reboot.  Perhaps leverage the ATA
password prompt process to ask the user to type "CONFIRM" or something
very explicit to unlock the flashing capability for that single boot
session.

Same goes for USB firmwares, and any other device firmware.  Either
provide a physical port for re-flashing, or find a way to make it very
hard to secretly flash the firmware.  

It seems cumbersome, but all that scary backdoor stuff people
hypothesized about 15 years ago actually began to happen 10 years ago,
and we're only now finding out about it.

tim
_______________________________________________
PLUG mailing list
[email protected]
http://lists.pdxlinux.org/mailman/listinfo/plug

Reply via email to