Hello Nico,
Monday, August 7, 2017, 2:16:05 PM, you wrote:
NH> Hi Philipp,
NH> On 05.08.2017 21:58, Philipp Stanner wrote:
Do we have any idea what exactly they do to update the firmware internally?
NH> Well, I don't. Though, the flash chip is usually only partially NH> protected (something like the upper 128KiB?). They probably only NH> update the unprotected part or put an UEFI capsule (or something NH> similar) into another part of the chip and update the protected NH> part from within the firmware on the next boot.
AFAIK the capsule is not written to flash. It's usually put into RAM or may be alternatively written to the EFI system partition on disk[1] (though I don't think I've ever observed that).
The wiki says once coreboot is flashed you can flash it internally. I suppose this means the blockade protecting the flash can be switched of somehow, as the vendor's have to do it to install firmware-updates.
NH> The upper most part of the chip is protected by a Protected Range NH> Register (PRR). These PRRs are reset on each reboot. So the only NH> chance to write to the protected region is during early boot before NH> the firmware writes the PRR.
NH> In case they do support updates to the protected region at all, it's NH> likely that the code therein writes the PRR. So it's the update mecha- NH> nism in the firmware that could be attacked (maybe it's just a check- NH> sum, who knows?). You probably can't flash a whole coreboot image this NH> way, but if you can make it write a modified firmware that doesn't set NH> the PRR (or locks it to all zero early), you'd have won.
NH> But first things first, we'd have to find out when the PRR is written NH> and whether the protected region is updatable.
You can use chipsec[2] to dump out the current configuration of the system and see if PRRs are indeed used (and how).
[1]: http://www.uefi.org/sites/default/files/resources/UEFI_Summerfest_Insyde_201... [2]: https://github.com/chipsec/chipsec