How could one really get sensitive information from a swap partition?

When I google this question, I only get all sort of information on how to protect sensitive data, how to encrypt swap, and how "dangerous" could be to keep a "normal" swap in a linux system.

But I couldn't find any software, method or "how to" in order to really get (read) any piece of data from a swap partition.

So my question is, being a "normal" citizen living in western Europe, is it really necessary to wipe or encrypt the swap on my computer? And before someone answer "yes", can I have an exemple on how I could test, and leak out my own swap, so that I can actually see what kind of data is unprotected despite my encrypted home?

Solution 1:

being a "normal" citizen living in western Europe, is it really necessary to wipe or encrypt the swap on my computer?

It is a personal judgement, one that depends on how much you value the privacy of your data, and how much you wish to protect your data from being exposed if it were to fall into the hands of an attacker. Suppose you have a laptop, and one day it gets stolen - how likely is that a thief would try to extract passwords or encryption keys or otherwise private data, and do you care? A lot of people do not care, but some do. Admittedly, most thieves would simply sell the laptop for immediate financial gain, but there are cases where an attacker might be motivated to go further in attempting to access the data itself.

And before someone answer "yes", can I have an exemple on how I could test, and leak out my own swap, so that I can actually see what kind of data is unprotected despite my encrypted home?

The memory of any process could potentially be swapped out to the swap space. Leaking memory can be dangerous - the obvious example being Heartbleed - see How I used Heartbleed to steal a site’s private crypto key. The memory that is exposed by Heartbleed only belongs to one single process, whereas the memory potentially exposed by your swap space belongs to every process. Imagine a process containing a private key, or password list (eg. web browser) being swapped out - those items will appear, in plaintext, in the swap space. Extracting them is a matter of sifting through the memory for particular patterns of data - it could be plaintext ASCII data visible through strings, or it could be more involved, as in Heartbleed (where the test is that some consecutive bytes are a divisor of the public crypto key). If you have an encrypted /home partition, then the obvious thing to look for is a block of data that forms the encryption key that will unlock the user's data.

A working example:

• do bash -c 'echo SECRET=PASSWORD > /dev/null; sleep 1000' to create a bash process with some secret data on its stack

• do sysctl vm.swappiness=100 to increase swappiness (not necessary, but may make the example easier)

• run top -c, press f, enable the SWAP column, press q to go back to top process view, scroll down until you see the bash -c process

• in another terminal, save Chimnay Kanchi's program from Linux: How to put a load on system memory? to usemem.c, compile it gcc -o usemem usemem.c, and run usemem & repeatedly in a terminal. This will use up 512MB blocks of memory at a time. (It does not matter what causes the memory to get swapped out, it could be normal system usage, a run away process, or a deliberate attack, the end result is the same)

• watch top, wait for bash -c to get swapped (SWAP column value > 0)

• now run strings /dev/sdaX | grep SECRET where X is your swap parititon

• Congratulations - you just extracted "secret" data from the swap partition. you will see multiple copies of the SECRET text followed by the "password", the copies that include the full command line leaked from the parent bash process, top process, and the 'bash -c' process. The lines that do not include the full command line have leaked from the 'bash -c' process.

• To prove that secrets leak from process memory, and not just the command line, add the line unsigned char secret[] = "SECRET=XXXX"; to usemem.c (just below the unsigned long mem; line). Recompile and run usemem & repeatedly, and strings /dev/sdaX | grep SECRET again. This time you will see the 'XXXX' secret being leaked.