7

In the case of a Live OS (i.e Tails) where filesystems are kept in RAM, is there any difference in the way a file is deleted ?

Specific case considered :

  • files "1.jpg" and "2.jpg" in a running Live OS
  • file 1 is deleted the normal way, file 2 is deleted with "shred" command
  • someone gets full RAM access immediately after (root rights or even physical RAM dump)
  • can any of these files content be recovered ?

I would like to know if there is any need to use a "secure erase" method and if yes, what is the best one available.

I know that reboots / RAM overwrite / RAM data loss when power is off will work, but the only case considered is for access immediately following the deletion while the OS is still running.

schroeder
  • 123,438
  • 55
  • 284
  • 319
msec24
  • 105
  • 3

3 Answers3

4

Running shred on a file in memory is pointless. The data from the file is also likely to be present in application memory, in caches, etc. Memory that belonged to a process it not wiped when the process dies: Linux, like most kernels, wipes memory before granting it to a process, not on release, because that's faster.

Of course, there's no guarantee that the file can be recovered. But there's no guarantee that it can't, either. If your attacker model is that the attacker can see your RAM content, there's a lot you need to take care of. At the very least you need to wipe RAM pages as soon as they're released by the process. You can apply the Grsecurity patches to the Linux kernel, at least the PAX_MEMORY_SANITIZE option. And you need to be careful about what processes are running and might store confidential information. And keep in mind that the kernel stores confidential information too, such as the RNG state and disk encryption keys. The TRESOR patch to the Linux kernel protects the disk encryption keys during normal operation, but it isn't a perfect defense and I don't know of a similar patch for the RNG state.

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
  • *data from the file is also likely to be present in application memory* - Wow, I completely forgot about that! Yeah, shred will only work on files that were never in a process' memory, which is a very limited number of files (initramfs files?). Pretty much any program but `stat` and `mv` will populate memory with the file contents. – grochmal Sep 05 '16 at 14:50
2

The danger you are trying to mitigate is filesystem journal, i.e. shred is not effective on filesystems that have a journal (e.g. ext3, ext4, reiserfs).

Assuming you are not using any unionfs for persistence (apparently you can do it in Tails although I never tried), everything is stored in a tmpfs.

The linux documentation on tmpfs does not detail whether is performs journaling. Yet, tmpfs is based on ramfs, the same filesystem that is used in initramfs, and that filesystem does not have a journal. Therefore it is (more-or-less) safe to assume that tmpfs does not have a journal as well.

On a filesystem without a journal shred will perform the overwrite of the file, making it difficult to recover with analytical tools (pretty much impossible to recover from a RAM dump). Since everything happens in memory pages, and the inodes of a tmpfs simply point to memory pages, using shred is much better because it will be able to write to these memory pages.

Caveat

The above certainly works in this way on Tails, and on Knoppix. It will likely work in a similar fashion on almost all Linux distros on LiveCDs, including Kali Linux yet there is a caveat.

This works for files! Memory will also contain application memory, see Gilles' answer on application memory. Seriously, look at that answer, it opens an important point.

Also a distro based on Ubuntu Linux (that may or may not include Kali Linux* since its predecessor, Backtrack, was based on Ubuntu) will mount any swap it finds on the machine it boots, which may leave a much worse attack vector! Persistent data on the device itself!

Another caveat with Kali Linux, is that it comes with metasploit and boots the postgres database for use with metasploit. Postgres has its own journalling (which is file based not filesystem based), which you may want to shred as well (i.e. shred the postgres files not just delete the data through psql).

* Kali is not based on Ubuntu, it is based on Debian, yet I am not confident whether it dropped all its configuration scripts from the time it was called Backtrack and was based on Ubuntu

Community
  • 1
grochmal
  • 5,677
  • 2
  • 19
  • 30
  • Are journalling filesystems used on LiveCDs? I assumed it used `ramfs` or equivalent. What does Kali do for non-persistent operation? – schroeder Sep 03 '16 at 20:59
  • @schroeder - I admit I'm being way too careful. Yet, there are linux distros that may use unionfs to mount part of a USB stick to make persistence. Therefore LiveUSB sticks may have some journal, e.g. [slax](http://old.slax.org/forum.php?action=view&parentID=24532). But moreover, even a LiveCD could create a file in tmpfs bind it to a loop device and (mke2fs and) mount it as, say, ext4. That sounds completely crazy, but possible. – grochmal Sep 03 '16 at 21:23
  • @schroeder - Good point. But I need to admit I never used Kali (Black Arch person here). Moreover there are some nasty things about Ubuntu LiveCDs (which I added to the answer), and am not sure whether Kali still have some of those problems from the time it was called Backtrack. – grochmal Sep 03 '16 at 22:00
  • @grochmal Journaling and persistence are indeed 2 important points. These put aside, if I understand correctly, the tmpfs memory pages are "closer" to HDD than SSD for that matter (secure erase are effective on them), is it correct ? – msec24 Sep 03 '16 at 22:34
  • @msec24 - I would say that that is correct, but not because of tmpfs. It is because DRAM chips cannot be analyzed to check what they did contain in the past. Once a DRAM chip is powered down you cannot retrieve anything from it. You can only get what is stored *right now* in a DRAM cell (a RAM dump for example). In other words `shred -n 1` is as effective as `shred -n 3` (the default), i.e. DRAM is even safer than HDD. – grochmal Sep 03 '16 at 22:43
  • @grochmal Many thanks, I was worried that some techniques that apply to SSD (wear leveling, over provisioning, deleting the inode only instead of the content, ...) may apply to RAM too, thus making shred useless, but that does not seem to be the case. – msec24 Sep 03 '16 at 22:51
  • Automatically mounting swap from a LiveCD is an amazingly dumb idea, even if you don't care about security. – CodesInChaos Sep 04 '16 at 11:58
  • Another option may be memory areas with the file contents. I guess overriding invalidates the read-cache, but this doesn't neccessarily mean its zerod or overrwritten with the shred output. And other RAM areas may contain parts of the file as well, maybe your image viewer loaded them into ram and they are still there. – allo Sep 05 '16 at 18:25
0

Use "shred", it zeroes out the inodes involved so there is no actual data in RAM anymore. This prevents coldboot attacks as well as online DMA attacks.

John Keates
  • 820
  • 4
  • 7