Anthony J. Martinez

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 [1] 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 [2] 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 [3] 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 [4] 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 [5] 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 [6] 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
--------

[1] https://github.com/mthbernardes/QMKhuehuebr/
[2] https://docs.qmk.fm/#/feature_dynamic_macros
[3] https://puri.sm/products/librem-key/
[4] https://puri.sm/posts/wrangling-the-ec-adventures-in-power-sequencing/
[5] https://forums.puri.sm/t/ec-protection-librem-14/15050
[6] https://puri.sm/posts/anti-interdiction-update-six-month-retrospective/