Prevent BIOS being flashed by root-level attacker without physical access?

[sampablokuper]

@Kyle_Rankin

Yes, if the user chooses to ignore the feature within Heads that alerts them to tampering (TOTP code) then attack #1 would work

Exactly. Thanks for confirming

but it would be better for the attacker to just […] display some other code and a user who isn’t checking the code at each boot (as they should) wouldn’t detect it.

That is a matter of psychology. Personally, I suspect that if a user is prompted to check a code, they are more likely to (remember to) do so than if they are not prompted to. But your disagreement with me about this is a minor quibble: if we wanted to settle it, and had the resources to do so, we would try the two variants of the attack on a sufficiently large sample of users to enable a statistically meaningful conclusion to be drawn.

The more important point is that without protection against internal flashing, this sort of remote attack will succeed against some set of users who would otherwise be protected.

Attack #2 is also possible […] We have tested this type of attack and it does work!

Again, thank you for confirming this.

but it would need to be custom-tailored for each user as each user’s BIOS will be slightly different (as it will contain their custom GPG keyring and settings) so the attacker would need to pull down their particular BIOS and couldn’t just use a standard Heads ROM.

I know. That is the reason for steps (i) and (ii) in my post above.

Our plan is to mitigate it for remote attackers by setting the ROM to read-only mode inside Heads at boot time. […] Currently we have added patches to Heads such that you can flash the ROM within Heads itself, but we haven’t yet added the feature that sets the read-only bit when it boots into the OS itself. Once it’s enabled though, the attacker would need to be physically present to be able to reboot into Heads to reflash the ROM.

Thank you. This is good to know.

It is not as strong a protection as a hardware switch, however. A hardware switch “just works”. Heads, on the other hand, is thousands of lines of code. A flaw in Heads could potentially render the ROM capable of being flashed from the OS or from firmware in other devices.

I am well aware that the original developer of Heads is the same as the lead developer of Thunderstrike 1 and 2, and is therefore familiar with that sort of risk and how to mitigate it. Even so, a hardware switch would not be amiss.

We also have some plans to mitigate it in the future for local attackers but we aren’t ready to announce anything along those lines yet.

“If you open the case, it blows up in your face!”

Seriously, though: by “local attackers”, do you mean attackers with physical access?

I realise that mitigating against a physically-present attacker who is using a port is possible, per Thunderstrike 1 and 2, via e.g. IOMMU and disabling option ROMs, etc.

I am not sure how to mitigate against an attacker who is using a SOIC clip, other than:

• using obscurely-headed case screws, with tamper-evident seals/varnish over them; and/or
• following Apple’s approach of using a BGA chip instead of a SOIC chip (to increase the difficulty of attaching to its contacts), and choosing a chip that few people know how to read from or write to over hardware.

I am intrigued to see what Purism has in the pipeline.

It’s important to remember that our goal with this is to detect tampering but while still allowing the user to completely control their device. That’s why by default we have Heads alert the user to tampering but we explicitly don’t prevent them from booting into a tampered system. We offer a particular “unsafe boot” option within Heads that allows exactly this (but sets the console background to be red to warn the user that this is risky) so they can boot into a tampered-with system to inspect it or otherwise fix it. Because innocent tasks like kernel updates have the potential to trigger this, we need to be careful about anything that would lock a user out.

Seems reasonable.

I still think a hardware write-protect switch is in order on this front.