Tails leaves traces of its existence in EFI vars upon kernel panic or oops (PELD 2.1.2 violation)

Severity: medium

Summary

The attacker can store information about Tails in cleartext on the computer it's running on.

To Do

• Set milestone to the upcoming release
  • We can fine-tune this later once we have assessed severity.
• Fill the Summary, Impact, "and Availability sections, so that:
  • We can assess the severity of this issue.
  • Our technical writers have the information they need to write release notes.
• Assess the severity of this issue according to our Security issue response policy
• Have the severity assessment confirmed by another Tails Team member
• Track the next steps, according to our Security issue response policy
  • The next steps depend on the severity of this issue.
  • For example: track when this issue can be disclosed, in a way that will survive this issue being closed and the corresponding MR being merged.
  • #20892 (closed)
• Decide whether we will do an emergency release or document mitigation measures

Impact

I see two main practical use cases for an attacker

1. Confirmation

a confirmation attack can be done. The attacker can trigger a kernel panic. Then they will put their hands on the real hardware, and find a confirmation.

2. Save now, recover when I have a rootkit

an attacker who is not able to deanonymize now, can force a kernel panic in order to store information: this is probably easier than deanonymization. Then they wait for a stronger attack to come, which allows them to be root. They'll be able to recover those information.

Availability

to store information, the attacker needs to trigger a kernel panic or oops. This is trivial with root privileges (sysctl kernel.sysrq=1; echo c > /proc/sysrq-trigger), but probably easier than this in many cases.

To recover the information, the attacker needs to be privileged-enough on any system running on the same hardware (ie: it doesn't need to be Tails).

Possible fixes

Adding efi_pstore.pstore_disable=1 to kernel boot parameters works. It doesn't retroactively remove what's in /var/lib/systemd/pstore/.

Details

Upon kernel panic and oopses, portions of the kernel log are written to persistent EFI variables for pstore. When Linux boots the next time, the previous boot's kernel log is available in /sys/fs/pstore (systemd moves it to /var/lib/systemd/pstore at boot). This violates PELD 2.1.2:

It is REQUIRED no trace is left on local storage devices unless the user explicitly asks for it

These logs reveal that the computer was used with Tails (kernel version and hostname "amnesia" is shown for example). It also reveals sensitive information such as AppArmor violations which can include filesystem paths with sensitive names.

This can be mitigated by adding efi_pstore.pstore_disable=1 to kernel boot parameters. The only effect of this mitigation is that the kernel log will not be written to persistent storage when a kernel panic or oops occurs.