Tails left traces of its existence in EFI vars upon kernel panics - Recently Patched

General
1

This issue was recently solved, but the fact that information was automatically being logged to NVRAM is…interesting.

From the GitLab page:

Summary

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

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.

1 Like
2

Could someone explain the end result risk of this in non-techncal terms?

A friend of mine experienced Tails behavior that sure does sound like this attack.

Booted up on Tails. Strange failure and crash of Tails for unknown reasons. Only happened a couple of times, but never again.

So, what is the risk on their computer? It was booted up on Tails, so that was the only Operating system used.

Is there something written to the computers hard disk somewhere?

What information did they gather from that attack? Does some entity now have identifiable information that puts the Tails user at risk?

(I tried to glean what I could from this post and the link but not sure I fully understand the end risk or how they should to “undo” something written to their computer?

3

Recently patched, meaning TAILS 7.0 fixes it?

4 
Could someone explain the end result risk of this in non-techncal terms?

If your Tails glitched in a certain way it dropped certain logs into your computer’s persistence storage thats on the motherboard (NVRAM). These logs may still be on a computer that has used Tails. Tails is meant to be completely aforensic (store no traces) and this can provide evidence that tails was used, or even worse, in some instances if can provide some idea of what it was used for.

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.

Example: Lets say you used Tails to anonymously blow the whistle about illegal CIA torture 3 years ago, using a chat provided by a journalist called WhistleBlowerChat to upload evidence stored on a veracrypt drive. You run it and it crashed your Tails PC (on purpose or not). You expected all traces of the activity to be gone because its Tails. Yet years later when you get arrested under suspicion of whistleblowing, the police might see something like this in your motherboard’s persistent storage:

Oct 10 10:00:00 user kernel: [123456.789012] audit: type=AVC msg=audit(1633934400.000:123): apparmor=“DENIED” operation=“open” profile=“/usr/bin/whistleblowerchat” name=“/media/amnesia/70a8c08b-ad80-4d4f-bb4e-abe5ca7cce82/LauraUohh/CIATortureExposed/evidenceforWashingtonPost/pictures” pid=12345 comm=“whistlblower” requested_mask=“r” denied_mask=“r” fsuid=1000 ouid=1000

Tails was supposed to be amnesic and prevent this from being recorded, but because of a kernel panic it decided to dump this in cleartext. This is patched now by logs like that may still reside, if I am not mistaken.

Recently patched, meaning TAILS 7.0 fixes it?

It is patched, yes. However this doesn’t mean that the data will get deleted. If you have used Tails in the past, there is a chance that the fact that your computer may have stored data that you didn’t want it to. The GitLab user provided a script that wipes this data. Or you can just take out your computer’s CMOS battery for 10 minutes and put it back in.

3 Likes
5

Yikes scary

6

Thank you for both taking the time to explain this and such a clear explanation with the solution. Very much appreciate this.

7

please note a lot of systems don’t actually correctly support the efi pstore function in my testing, so even though this was an issue, it likely impacted very few people since it required: both a crash and support from the system.
that being said, it is a bad issue for those few affected if they chose tails for its amnesiac capabilities.

this is actually unlikely to do anything on modern (<15 years) systems, since they use persistent flash

8

You mention that disconnecting the CMOS battery will not “erase” this stored error message from Tails because it is still in “Persistent flash”.

Is there any real-world solution to clearing this error code?

edit: Will flashing a new BIOS clear the stored error codes?

9

I’m hoping I found the answer to clearing the “Persistent flash” memory on a Windows PC.

  • Update Bios (flash)
  • Restore Windows to manufacturers original settings. (like restoring from complete failure)

Can someone confirm or correct this answer?