Red Hat Bugzilla – Bug 439434
Passwords can be read from RAM
Last modified: 2014-03-16 23:13:23 EDT
Description of problem:
A few weeks ago I read an article about reading passwords from RAM that had been
cooled. Now the threat has been expanded and now can be read with a software
application. The passwords in question pertain from application or file
passwords to full system encryption.
As a security issue, this should be looked at being resolved sooner than later.
To quote the article.
It turns out both Windows and Linux retain "boatloads and boatloads" of
passwords in memory, said Sherri Davidoff, a security analyst with
IntelGuardians, the penetration-testing firm that developed the tool. It's
already been able to isolate passwords for Thunderbird, AOL Instant Messenger,
GPG, SSH, Outlook, Putty and TrueCrypt, among others, and with additional
research they believe they can find many more.
"The idea here is let's see if we can hit an office building, get in and out in
25 minutes or less and walk out with some interesting passwords," said Tom
Liston, an IntelGuardians security consultant who along with Davidoff
co-presented the tool at the CanSecWest security conference in Vancouver.
For now, DaisyDukes remains very much a beta program, so it's not yet suitable
for production. But it already shows great promise. For one, it's highly
compact, which prevents the boot sequence from overwriting old data stored in
the computer's RAM. For another, it's highly flexible, making it possible to
sniff the password for a single application or grab the entire contents in memory.
And that could prove a game-changing development for penetration testers, who
regularly walk into a customer's premises and look for opportunities to walk out
with a laptop or server. Customers have grown accustomed to being unconcerned
about such breaches when the purloined machines have disk encryption or are locked.
Hopefully as part of Fedora's move to greater security, this will be looked at
sooner than later. At least it is an issue for Windows as well. With the
progress from pulling passwords from the ram by moving the ram, to a USB drive
based application in only a few months, I suspect that there will be virus or
other tools that will be able to do this already in the works.
By the article, very reproducible.
Steps to Reproduce (at present):
1. Download the software
2. Install on a USB disk.
3. Get system to boot and run the software.
When the software runs, it cannot get copies of the passwords or keys.
This is a request for enhancement and needs to be addressed sooner than later.
Random ideas and suggestions.
I would suggest a way making the passwords disappear from ram after being used.
Also that any application that uses a password in ram to actually erase the
password after opening the file.
Have the OS create an encrypted (different random key) on each boot process for
password usage. Maybe a kernel module or something that can be called from an
application for password usage (API) that is being used in RAM.
The idea that I have is if I use TrueCrypt, I enter in the password and the
kernel then encrypts the password using a random key. When TrueCrypt needs to
access the password, it calls the API or kernel module to get access to the
kernel encrypted password that is held in RAM. If the machine is then shut down
or the RAM is read, the password is now encrypted.
This will be needed to be sent upstream to developers for any product that uses
I want to add to this from my home account.
I think that the application and the kernel would have to have a secure method
of keeping the password secure. The password would have to be tied to the
application and the kernel module couldn't decrypt it for a different application.
Something like PGP but at a kernel level. When an application starts, it could
generate a private/public key based on the some different random variables. A
second token could be created when the application requires the use of the
password. These then could be used to communicate between the kernel and
application. Hopefully something could be done so no memory dump could point to
the specific tokens used for the password.
Some ideas for tokens that wouldn't need to be in ram but tied to the machine.
Application serial number. Could be in a config file or user file.
Number of users in the password file on the system at the time of start.
Number of characters in the password file as the time of application/system
start or user login.
Data in some random inode.
The more I think about this, the harder it gets to figure a way around the problem.
The method would have to overwrite the ram after using the password or
calculating anything to do with the password.
Thats a more kernel/distribution related bug though, so i'm reassigning it to
the proper component so it gets the right attention.
Read ya, Phil
I'd like to see some proof that this actually is successful at finding passwords
on a Fedora system before spending too much effort on this. It sounds scary on
paper, but until I see something concrete involving a Fedora system and not just
some unnamed "Linux" I think it's a bit premature to act. Also, given how many
different applications store passwords differently this likely will end up being
an application by application fix, not something that can be done globally
(except for maybe the things that use gnome-keyring). I wouldn't be surprised
if Firefox/Thunderbird hit on Linux, given that they hit on Windows.
If you can find proof that this actually happens on a modern day Fedora system,
please re-open the bug and point out said proof.
I understand your concern.
I found the link for the full paper.
I have copied and pasted the two important parts in regards to Linux. TrueCrypt
As I understand it, both of these programs work at a kernel level so they would
be cross system unless Fedora actually changed the kernel. But the procedures
are provided in detail.
The paper does provide some ideas to make it harder to carry out the one attack
without any changes. (RAM check on reboot and bios passwords for access and boot.)
From the paper, Microsoft does provide some information on how to make BitLocker
A test for Linux is provided here. It requires physically crashing the system
I will see if I can find out more information.
I still feel that this is important.
----------------Copy and paste.
TrueCrypt is a popular open-source disk encryption product for Windows, Mac OS,
and Linux platforms. It supports a variety of ciphers, including AES, Serpent,
and Twoﬁsh. In version 4, all ciphers used LRW mode; in the current version,
version 5, they use XTS mode (see Section 5.3). TrueCrypt stores a cipher key
and a tweak key in the volume header for each disk, which is then encrypted with
a separate key derived from a user-entered password.
We tested TrueCrypt versions 4.3a and 5.0a running on a Linux system. We
mounted a volume encrypted with a 256-bit AES key, then brieﬂy cut power to the
system and used our memory imaging tools to record an image of the retained
memory data. In both cases, our keyfind program was able to identify the 256-bit
AES encryption key, which did not contain any bit errors. For TrueCrypt 5.0a,
keyfind was also able to recover the 256-bit AES XTS tweak key without errors.
To decrypt TrueCrypt 4 disks, we also need the LRW tweak key. We observed
that TrueCrypt 4 stores the LRW key in the four words immediately preceding the
AES key schedule. In our test memory image, the LRW key did not contain any bit
errors. (Had errors occurred, we could have recovered the correct key by
applying the techniques we developed in Section 5.3.)
Linux kernels starting with 2.6 include built-in support for dm-crypt, an
on-the-ﬂy disk encryption subsystem. The dm-crypt subsystem handles a variety of
ciphers and modes, but defaults to 128-bit AES in CBC mode with non-keyed IVs.
We tested a dm-crypt volume created and mounted using the LUKS (Linux
Uniﬁed Key Setup) branch of the cryptsetup utility and kernel version 2.6.20.
The volume used the default AES-CBC format. We brieﬂy powered down the system
and captured a memory image with our PXE kernel. Our keyfind program identiﬁed
the correct 128-bit AES key, which did not contain any bit errors. After
recovering this key, an attacker could decrypt and mount the dm-crypt volume by
modifying the cryptsetup program to allow the raw key to be input.
This is quite likely exploitable on any modern system, Fedora included. Without
dedicated tamper-proof hardware, it is always going to be possible to retrieve
keys from RAM. It's the nature of the system.
If you feel you have ideas that would not be vulnerable to this attack, you
would be better off writing some demo code proving your ideas, and why they
don't suffer from this problem (nothing I've seen in this bug so far would be
free from RAM snooping). The solution for the truly paranoid is to get a
dedicated tamper-proof hardware encryption device. The rest of us will have to
rely on powering our machines off (for now).
If you want to further fuel your paranoia, I suggest you look over these papers:
This is not a new problem. What is new is that someone found an easy way to
acquire the contents of memory.
The real world implications of this are not quite what they appear to be though.
A successful attack of this nature will need to be very targeted. If you are a
person who handles very sensitive data, and you need maximum security, I suggest
you keep your sensitive information on something like a flash drive, and only
mount the drive when you actually need the data on it.
I would love to write some code but at this time, I am just getting back to
doing "Hello World" in C again. To many years since the last time I wrote any
code. :) I finally have to write some code so back to the tutorials for my
I have some ideas but putting them into words that others can use to run with
will take some time and investigation. Also some more time to understand how
some of this can be controlled.
Some of my thoughts have already fallen through in my own mind, especially after
reading about the different tools that can read RAM.
As for sensitive material, with the increased government intrusion into private
lives, the need may become higher for standard individuals. Also criminals whom
love to steal your credit and bank info would love to be able to grab your
credit card/bank details using a simple hack.