Attention is currently required from: Benjamin Doron, Nico Huber.
2 comments:
File Documentation/drivers/smmstore.md:
An attacker could mess with future calls into the APIs, but they
can already do so: Other common APIs for boot level variable are
implemented in RAM as well, so they can easily be defused.
nit: variables? Also, are you thinking of coreboot CMOS or UEFI variables here? Or both, I suppose. […]
The attack vector is overwriting the UEFI entry point to the variable functions which isn't in SMM but in RAM: the modified-UEFI could then pretend to do whatever variable updates were requested that it doesn't want to see done (e.g. installing a blocklist), and even cache the data for the current run to return "good" values, but never actually write it down.
In terms of UEFI Secure Boot: suppose some malicious boot level code is accidentally signed with a valid key, and the system wants to push a dbx update to block that malicious code from being accepted. On systems where that code already runs, to ensure its own persistence across boots it could intercept SetVariable and GetVariable and pretend that dbx is updated when it isn't.
But yes, I need to see how to put that in the doc more clearly, so thanks for the feedback.
As a remedy, CLEAR could be disabled after the initial repacking,
within the boot process, so that SMMSTORE becomes an append-only
store. In this case, the attacker could fill up the buffer, leading
to a DoS of the variable store until it's repacked. As described
earlier, once there's an attacker on the system, the variable store
lost its function until the attacker has been evicted, anyway.
Raw WRITE has to be protected to, because writing 0xFF is equivalent to clearing. […]
Raw write from outside SMM is supposed to be disabled in the SMMSTORE model, yes. I'll make that clearer. SMM is used to ensure that the flash region becomes append-only (except for CLEAR)
To view, visit change 79095. To unsubscribe, or for help writing mail filters, visit settings.