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. How reproducible: 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. Expected results: 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 passwords.
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. Processor information. User name. 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. Thanks, 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. http://citp.princeton.edu/pub/coldboot.pdf I have copied and pasted the two important parts in regards to Linux. TrueCrypt and dm-crypt. 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 better. A test for Linux is provided here. It requires physically crashing the system to test. http://citp.princeton.edu/memory/exp/ I will see if I can find out more information. I still feel that this is important. ----------------Copy and paste. 7.3 TrueCrypt 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 Twofish. 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 briefly 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.) 7.4 dm-crypt Linux kernels starting with 2.6 include built-in support for dm-crypt, an on-the-fly 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 Unified Key Setup) branch of the cryptsetup utility and kernel version 2.6.20. The volume used the default AES-CBC format. We briefly powered down the system and captured a memory image with our PXE kernel. Our keyfind program identified 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: http://www.google.com/search?q=data+remanence+volatile+semiconductor+memory 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 aging mind. 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.