Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • A archiso
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Graph
    • Compare
    • Locked Files
  • Issues 41
    • Issues 41
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 11
    • Merge requests 11
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Arch LinuxArch Linux
  • archiso
  • Issues
  • #189
Closed
Open
Issue created Aug 12, 2022 by Tallero Tallero@talleroContributor

USB install drives are vulnerable to "evil maid"s

physical keys

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.12

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 on this fork and is pretty much stable at this point.

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.

A correspondent bug has been opened on main arch bugtracker (FS#75585) (now closed).

Note (3/9/22): I'm not concerned on backporting my changes back upstream anymore. If no one else is interested and it is an issue I'm publishing them in my namespace I will move them somewhere elsewhere if needed.

References

  1. Authenticated Boot and Disk Encryption on Linux, Lennart Poettering, 2021 ↩

  2. gpn20 - PoC: Implementing evil maid attack on encrypted /boot, Christian Schneider, 2022 ↩

Edited Sep 04, 2022 by Tallero Tallero
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking