Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#75585 - USB install drives are vulnerable to "evil maid"s

Attached to Project: Arch Linux
Opened by Pellegrino Prevete (tallero) - Friday, 12 August 2022, 12:20 GMT
Last edited by Morten Linderud (Foxboron) - Tuesday, 23 August 2022, 17:33 GMT
Task Type Bug Report
Category Security
Status Closed
Assigned To Jelle van der Waa (jelly)
Levente Polyak (anthraxx)
Morten Linderud (Foxboron)
Jonas Witschel (diabonas)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Problem

Since USB drives are not write-once, an evil maid can easily replace the whole content of the drive with something else, letting an unaware user install an already compromised system.

More in general any system residing on disks in a BIOS or UEFI computer not protected with secure boot seems vulnerable to this kind of attack.

Encryption is not relevant as defense since the attacker can always replace the bootloader and the kernel to acquire the necessary data from the user himself. [1]

Proposed solution

The easiest feasible mitigation I've found for maids able to alter or replace storage (NB: I suppose we're just scratching the surface here) is to move kernel, bootloader, checksums and signatures on a separate safe dongle device.

This solution is implemented in https://gitlab.archlinux.org/archlinux/archiso/-/merge_requests/279.

While people are usually not concerned about physical attackers, we should explicitly advice users not to use any single writable drive setup for more than a couple sessions and always refer them to an iso+dongle buildmodes combo, or simply enable it by default.

References

[1] Fitting Everything Together, Lennart Poettering, 2021
https://0pointer.net/blog/fitting-everything-together.html
This task depends upon

Closed by  Morten Linderud (Foxboron)
Tuesday, 23 August 2022, 17:33 GMT
Reason for closing:  Won't implement
Additional comments about closing:  This is not something that Arch can solve.
Comment by Pellegrino Prevete (tallero) - Friday, 12 August 2022, 12:34 GMT
Sorry, wrong reference:
Authenticated Boot and Disk Encryption on Linux
https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html
Comment by Pellegrino Prevete (tallero) - Friday, 12 August 2022, 13:57 GMT
Another reference:
gpn20 - PoC: Implementing evil maid attack on encrypted /boot
https://www.youtube.com/watch?v=5HCZXWfIk5Y
Comment by Toolybird (Toolybird) - Saturday, 13 August 2022, 23:38 GMT
Why is this in the bug tracker? It's *forever* been the case that "all bets are off" when it comes to physical access, it's just common sense. There is no actionable packaging bug here so I'm tempted to close this as melodrama. But I will assign to some security team members who can decide what to do with it.
Comment by Jelle van der Waa (jelly) - Sunday, 14 August 2022, 10:05 GMT
I honestly don't understand this bug report nor what the linked merge request achieves (please expand what the MR achieves, what it changes and wy). If this about creating a usb dongle which has to be inserted for the system to boot then this is really up to the user to configure it, if it is even applicable to their threat model.

However is this simply about an "evil mad" attack then this is up to the user to prevent and setup secure boot.

Loading...