dumping existing firmware and showing cryptographic hashes

[hodefoting]

Given the scope of fwupd and the code it needs to communicate with various types of hardware with firmware, it seems natural to extend the functionality to be able to read back the existing firmwares (and apply a cryptographic hash to the dumped contents). This would permit running this on a booted system, and then later check against a reference dump. Or even compare with dumps on other machines of the same model. Such a preventive measure does not protect against malicious firmware that might be altering the readback behavior of the device; presenting a valid image. It will however raise the bar for writers of malicious firmwares. Like keyloggers in the embedded controllers of thinkpad as demonstrated in this talk: https://media.ccc.de/browse/congress/2010/27c3-4174-en-the_hidden_nemesis.html#video

[hughsie]

I had a play at implementing this last night. It's trivial to do for ColorHug (which isn't so interesting) but kinda hard for BIOS -- which is probably the most useful thing :(

I tried using flashrom -r dump.bin on both my desktop and my laptop, but neither could work (active ME and unsupported laptop) which was my first thing to play with. Using dd if=/dev/mem I had to guess the offset and length and I couldn't find any values that could work for all hardware, and even if I did, the firmware doesn't need to expose all of itself in those ranges and can copy from shadow ram.

Video ROM is easily accessible find /sys/devices -name "rom" but I'm guessing this isn't so useful for hiding malicious firmware. I think co-operation with the hardware vendors is probably the only way to get proper access to read and write to the hardware properly. Ideas welcome :(

[hughsie]

I've pushed some test code to master, which gives the following output when doing fwupdmgr verify:

 * Verifying firmware from device
969b5b9d-a475-f36b-fdf5-60f405d3dd4b    f21e1d2c969dedbefcf5acfdab4fa0c5ff111a57    No metadata
2082b5e0-7a64-478a-b1b2-e3404fab6dad    39efec8eb324085843376073c7c65c0a5f42c4c8    Failed: for v2.0.3 expected 40b59e37cb918f3241f65bc5ac2b90ab47b34e8c

This is with my ATI graphics card (no vendor support) and a ColorHug2 with a non-official image flashed. Is this something like what you envisaged?

[hodefoting]

Yes - this is along the lines of what I was thinking, and I believe both NICs and GPUs might be suitable locations for hiding malicious code; these peripherals might have access to all of RAM and snoop/take screenshots and do other curious things.

[hughsie]

We now support ATI, Nvidia and Intel graphics VBIOS -- there is a slight complication as some vendors have started putting the device serial number in the flash, and we probably also need to regenerate the internal checksums to make the hashes the same for identical hardware. We can also us the new NVIDIA signing certificates in the blob to verify the firmware too, although I don't know what is actually being signed (assumed just the option rom segment...).

[hughsie]

You can also do:

$ fwupdmgr verify
e9b8eebd-b5f8-18d4-9fbd-d7da7711985c    f21e1d2c969dedbefcf5acfdab4fa0c5ff111a57    No metadata
$ find /sys/devices -name rom -exec sudo fwupdmgr verify-update /var/cache/app-info/xmls/fwupd-verify.xml {} \;
$ fwupdmgr verify
e9b8eebd-b5f8-18d4-9fbd-d7da7711985c    f21e1d2c969dedbefcf5acfdab4fa0c5ff111a57    OK
$ # flash the firmware
$ fwupdmgr verify
e9b8eebd-b5f8-18d4-9fbd-d7da7711985c    5c946b3950deaf7b102e75be488052afd4dcf16 Failed: for v013.012.000.019.000000 expected f21e1d2c969dedbefcf5acfdab4fa0c5ff111a57

Or you can generate metadata using .rom files from something like http://www.techpowerup.com/vgabios/ -- although we don't actually trust the data there, so I'm hesitant to add it. What we really need is vendors to securely add known-good hashes to the database, or to get them to ship signing certificates like Nvidia have started doing (although, we still need to RE the NVGI format...)

[comotion]

Nice. Research supports the feasability of firmware attacks on NICs, GPUs and harddrives among other devices, see for instance http://ids.cs.columbia.edu/sites/default/files/ndss-2013.pdf

[hughsie]

I'll close this issue now we have all the pieces in place; I'll add support for more hardware as this becomes available. I'm still super-keen to be able to dump the thinkpad EC.