PureBoot's Missing Feature
Purism's PureBoot offering on their products misses a critical feature:
Inspection and validation of the EC firmware.
Purism claims this is not a vulnerability, but a feature not yet implemented. It is on a roadmap that lacks dates that could be shared, according to Purism's CSO.
Read the full report below.
As Reported to Purism
The Full Report
Lack of EC validation risks undetected hardware backdoor in the Purism EC Summary -------- The discussion around this vulnerability started when Anthony J. Martinez forked the Librem EC project and created a branch to add numpad functionality. Upon successfully building, flashing, and using the newly crafted EC firmware both Anthony and John Marrett were concerned by the lack of notification or warning from PureBoot. The integration of the keyboard firmware into the EC code seemed a promising avenue for attacks. The keyboard firmware being based on QMK made it easy to explore the code base and look at prior art. Considering the possibilities we identified two promising avenues of attack: - Command injection where a common keypress is used to launch an attack - A keylogging attack Command Injection -------- The QMKhuehuebr  project on GitHub implements an attack where, when the user presses Super+L (the default lock key on PureOS), a sequence of commands is executed before the lock. This attack can be used to launch and persist a shell script or binary from a web source and use it to gain persistent access to the user account Keylogging -------- Making use of the Dynamic Macro  feature of QMK an attacker could program the firmware to record the first characters typed after boot. This would include disk and OS passphrases entered during boot up. This information could easily be persisted in RAM as long as the PC was powered on, possibly including standby. More concerted development could allow the attacker to store the recorded keystrokes in the EC firmware space, though this would be more complex to implement. The recorded keystrokes could be recovered by the attacker either through physical access to the device. They could also be transmitted to a remote server by combining the keylogging attack with the command injection attack described above. Protection -------- It's not clear to us how this attack can be prevented. The best method would be for the EC to be validated before being loaded or by PureBoot; however, we are not certain that this can be done. Our understanding is that the EC handles boot processes prior to these systems being initialized. There are a few important questions in this space as well: Can this attack be stopped if the user makes use of the Librem  key? We can still flash the EC, though it would require disassembling the laptop to access the EC flash chip as discussed in this blog post  on EC booting issues. Based on Purism response: The Librem key will not prevent EC access and flashing. Can you prevent booting from USB on the Librem 14? Does the Librem default, when purchased, to a configuration requiring a password to boot from USB? Based on Purism response: Will not be implemented. Restricts user freedom. It will be possible to disable EC writing using DIP switches  which would protect against a remote attacker compromising the firmware. We question the effectiveness of this as a means of protection as this class of vulnerability is best suited to an evil maid type of attack. Based on Purism response: Being implemented, with no clear timeline. Proof of Concept -------- We have not developed a proof of concept for this attack, but we may do so at a later point in time. Vendor Response -------- Purism is working on enabling the DIP switches to lock EC writing and suggests the use of glitter nail polish  to make tampering evident. They state that this issue is common to the entire industry and not specific to their product line. They also prioritize user freedom over solutions that would lock the user out of the EC. Purism has declined to request a CVE to identify this vulnerability, but do acknowledge that an actual vulnerability exists. Conclusion -------- From our perspective: - Modification of the EC will allow an attacker to subvert the mechanisms that follow it, including PureBoot functionality - Requiring a password to boot from USB would increase the difficulty and evidence of this attack at low cost - The use of the DIP switches may be the only technically feasible solution that is possible at this time - Respecting user freedom is extremely important - Cryptographic validation of the EC, ideally allowing the user to sign their own firmware, is the only completely effective solution to confirm that the security of the device has not been compromised Timeline -------- 2021-12-05 Initial communication of vulnerability to Purism security contact 2021-12-06 Initial response from Purism team, discussion follows, all delays on researcher side 2021-12-20 Final response from Purism team 2021-12-27 Revision of vulnerability write up based on discussions References --------  https://github.com/mthbernardes/QMKhuehuebr/  https://docs.qmk.fm/#/feature_dynamic_macros  https://puri.sm/products/librem-key/  https://puri.sm/posts/wrangling-the-ec-adventures-in-power-sequencing/  https://forums.puri.sm/t/ec-protection-librem-14/15050  https://puri.sm/posts/anti-interdiction-update-six-month-retrospective/
It is no secret that I have been a vocal supporter of Purism and their efforts to bring Open and Secure systems to the masses. This often comes at a price premium which is understood to actively support the high quality development of libre software and systems. Omitting, in design, a check so critical while simultaneously posting with great frequency about the extreme level of security offered does not sit well with me. Attempts to contribute resolutions to other identified gaps have gone nowhere beyond making this vulnerability clear. Then there is the Librem 5 debacle, which further erodes confidence in the company itself. As my hardware already in hand works, I will not turn it into eWaste. I just cannot, in good faith, add to it or suggest it to anyone else.