Version: ToT
OS: ChromeOS

What steps will reproduce the problem?
(1) flashrom -r /tmp/bios.bin
(2) Tamper to firmware string in RW sections (RW_FWID_A, RW_FWID_B)
(3) Reboot

What is the expected output?
Firmware should not boot

What do you see instead?
Firmware boots fine and stating itself as the tampered firmware ID.


This was discovered when I was debugging https://code.google.com/p/chrome-os-partner/issues/detail?id=52568 .

When RW_FWID_A content is changed, the following command would still success:

  vbutil_firmware --verify VBLOCK_A --signpubkey rootkey --fv FW_MAIN_A.

Checked with Randall:

It's expected, but undesirable in that you can freely tamper with them.  The version strings are a copy of the actual string in FW_MAIN_A, placed at the end just to make it easier to parse the binary.  This is left over from the original UEFI H2C BIOS.

Note that extending the signature to cover RW_FWID_A is undesirable, because the actual firmware inside FW_MAIN_A usually doesn't go all the way to the end of its region.  So right now, FW_MAIN_A is a 4MB region, but probably only contains a 2-3MB image.  We only need to hash and sign the actual image size.  If we appended RW_FWID_A to FW_MAIN_A, we'd need to hash and sign the entire 4MB block every boot.
 
Will it be an exploit if some people just tampered RW_FWID_A to fill a very long string that causes buffer overflow exploit?

Hopefully the users of RW_FWID_A do safe string copies (vboot does, the last I looked).  AFAIK the firmware itself does not use that string, so the exploit would be limited to things like the autoupdater (except that it's mostly bash, so handles long strings fine).

Note that this doesn't affect the integrity of verified boot roll-forward / rollback, because those are based on versions inside the vblock itself.  

But in the absence of a version change in the vblock, it could cause the updater to skip a RW firmware update.  (Which, again, isn't exploitable - because if we really wanted to make sure the update occurred to fix some security bug, we would rev the version in the vblock).

Maybe we can swap the locations of RW_FWID and FW_MAIN for new devices, and have the VBLOCK signature cover both?  That'd avoid the padding-caused performance problems described below.