PGP ID: 0xBD83B92B2F4BFD99
Fingerprint: 7B85 0961 8D82 0DF6 39241BB6 BD83 B92B 2F4B FD99
Latest posts by Kyle Rankin (see all)
A modern computer has many different avenues for attack—ranging from local user-level exploits to root and kernel exploits, all the way down to exploits that compromise the boot loader or even the BIOS—but for over ten years the Intel Management Engine—with its full persistent access to all computer hardware combined with its secretive code base—has offered the theoretical worst-case scenario for a persistent invisible attack. The recent exploit from the talented group of researchers at Positive Technologies moves that worst-case scenario from “theoretical” to reality. While the proof-of-concept exploit is currently limited to local access, it is only a matter of time before that same style of stack smash attack turns remote by taking advantage of systems with AMT (Advanced Management Technology) enabled.
At its core, Purism fights for ethical computing and believes that free software is the best way to protect a user’s freedom, security, and privacy. This belief has meant investing in removing software that fails to provide these protections (due to their proprietary/non-free nature). From the beginning, Purism has seen the ethical issues and potential for abuse in the ME, and fought against the inclusion of the ME in CPUs starting with petitioning Intel for an ME-less design in 2016, then reverse engineering parts of the ME in 2017, to collaborating and cooperating with the other groups cleaning the ME—resulting in Purism being the first manufacturer to disable the Intel ME in modern hardware.
The recent Intel Management Engine exploit has left many wondering how they can protect themselves, not just from this attack but also any future ones that exploit software sitting at such a fundamental level on their computer.
Purism offers one of the most advanced approaches by combining secure hardware, TPM, coreboot, Heads, and the FSF-compliant PureOS in its Librem laptops, helping protect against a wide variety of ME, BIOS, and boot-loader attacks beyond just wiping ME code from the computer. Below we will discuss how Librem laptops can help protect against the current ME exploit and describe some of the limitations of these countermeasures.
Part 1: disable & neutralize the Management Engine
The first way that Purism protects against the current ME attack is by disabling the ME and then removing (“neutralizing”) the majority of the ME code/modules. Because this removes and disables the ME module and AMT featureset (in addition to the various measures we had already taken to prevent AMT from working), users are protected against any future remote ME attacks that rely on AMT. This still leaves the local ME exploit. Like with many other computers, Purism doesn’t prevent you from flashing your own system with a previous BIOS or a different BIOS entirely; it’s important to offer users freedom to upgrade their hardware. Unfortunately, this trade-off means that even if the current state of the ME firmware on a Librem isn’t vulnerable to an exploit, an attacker could take the extra step of rolling the code back to a vulnerable version first, then attacking.
Part 2: thwart attempts to rollback into a vulnerable state
Mitigating the rollback attack is more challenging, but Purism offers one solution using the TPM chip made available with all new Librem laptops and Heads. With this solution, Heads will measure the BIOS and ME code at boot time, compare them with signatures stored in the TPM, and alert the user if that code has been tampered with. By doing so, the user is alerted to any attacks that have altered the ME or the BIOS in a persistent way—allowing the user to know the system needs to be considered “compromised” (or “untrusted”), so that they won’t perform any trusted actions (such as entering disk encryption passwords or other secrets).
The TPM/Heads solution has a few limitations if an attacker has physical access, foreknowledge of the Purism system and is willing to expend a lot of extra effort. The TPM/Heads solution relies on the boot guard module within the ME when it asks the ME to provide data for measurement. Because the current ME exploit attacks a part of the ME above boot guard, malicious code could (in theory) give false information to the boot guard and therefore to Heads. Fortunately, this attack is non-trivial in practice: it would require the attacker to:
- know about the use of the TPM and Heads on the system before they exploit;
- take their own measurement of the current ME before they change it;
- modify their exploit code so it provides that specific faked measurement to the boot guard.
Without these extra steps, Heads would detect the tampering.
Part 3: leverage TPM + Heads to protect against further exploits
In addition to this specific Intel ME exploit, the TPM/Heads solution protects against a much wider range of software tampering, rootkits and other attacks. Heads can detect tampering from the ME, to the BIOS, to the boot loader, to the kernel and initrd—and even to the whole root file system if you so choose. This wipes out entire classes of attacks, and leaves an attacker stuck—with no place to persist their attack or hide their tracks.
This means that each time you boot your system, you get a strong assurance that the system is “clean” and that there is no exploit hiding “somewhere you can’t detect it.” When you can trust your system, you are empowered to type disk encryption passphrases, login passwords, or other secrets in the system without worrying the system is working against you.
Conclusion and future avenues
Of course, we aren’t stopping with TPM and Heads. Defense in depth is important and so we are also exploring different ways to alert on—and protect against—attacks where the attacker has physical access to the machine and can take it apart. While it can be very difficult to protect a machine against someone with physical access, a number of solutions do exist, ranging from low-tech solutions like glitter nail polish all the way to tamper-evident hardware switches or other means. We are researching a number of different ways to add physical tamper proofing to our products, and if you would be interested in such a feature or have a favorite approach you’d like us to consider we welcome your feedback—at firstname.lastname@example.org!