From paul.suh at ps-enable.com Wed Mar 5 07:46:28 2008 From: paul.suh at ps-enable.com (Paul Suh) Date: Wed Mar 5 07:46:38 2008 Subject: [Newsletter] RAM Cold-Read Vulnerability, Poorly Protected External Drives, Other Problems with External Drives Message-ID: Folks, This newsletter has mostly security-related content. RAM Cold-Read Vulnerability ----------------------------------------------- There's been a lot of concern recently about how you can steal the FileVault key out of RAM after a machine has been rebooted. The primary website is here: and it has a link to the actual paper if you want to read the details. This is a serious concern for people who need to maintain the confidentiality of documents in the face of laptops that may be lost or stolen. So, given this, is this attack feasible in the real world, what is the likelihood that you may face this attack, and how can you reduce the risks? First, the attack is feasible. Ed Felten is a very reputable researcher and he showed the proof of concept. The technology for conducting this attack is not exotic or rare. The way it works is that RAM can hold its contents for a while even after it loses power; the colder it is, the longer it will hold the data. The attackers chilled the RAM in a running computer by using either Freon (easy) or liquid nitrogen (hard), and were able to recover data with fractional error rates (0.18% after 80 seconds). They could then search through the recovered data to recover the encryption keys for various whole-disk encryption systems, including Windows' BitLocker, Mac OS X's FileVault, and the open source TrueCrypt system. Second, what is the likelihood that you will face this kind of attack? A lot depends on your data and who stole it. Some random thief who smashed in your car window is unlikely to have the level of sophistication that would allow for such an attack. On the other hand, it is not out of the question for organized crime gangs to conduct targeted thefts of laptops from people who work at particular organizations in order to gain access to social security numbers and other personal information. Of course, some of the people reading this may work for government agencies that deal with Classified, Secret, or Top Secret data -- and are definitely targets of foreign espionage operations. The problem is that if your laptop is stolen you don't know who stole it -- and whether it is a targeted attack or not. If the value of your data is high enough or your data are covered by legal requirements, you have to treat it as though it was a targeted attack. So what are the potential countermeasures? There are several that are suggested in the paper, but only one is in the realm of the user or sysadmin: shut down your laptop rather than putting it to sleep, and wait a minute or so before you leave it alone to be sure that all of the data in RAM have been scrambled. (Most of the systems they tested had the RAM scrambled after less than a minute at operating temperature.) I have another suggestion which is not foolproof but will make it less likely that someone can recover your encrypted data. Have a separate encrypted disk image and make sure that it is not mounted when you put the system to sleep. After unmounting the disk image, run a little utility that allocates as much RAM as it can (forcing other apps to be swapped out to virtual memory), writes zeroes to all of the memory it just allocated, and quits. No, I don't have this utility, but it wouldn't be hard to write. This maximizes the probability that the encryption key will be overwritten, but it's not guaranteed and a lot depends on how RAM is mapped to different processes and whether the kernel keeps copies of the encryption key and its associated pre- computed key schedules in wired-down memory that can't be swapped out. Another potential attack vector is the hibernate image that gets written to /var/vm if a laptop's power gets too low. The hibernate image is encrypted, but the key must be present somewhere, otherwise it would be impossible to restore the hibernate image. I would recommend disabling hibernate mode by using the command: pmset -a hibernatemode 0 Poorly Protected External Drives ------------------------------------------------ Another potential attack vector are external drives that are supposedly protected, but are not in fact secure. One was examined by Heise Security, who found that the drive's *key* was strongly encrypted, but that the actual encryption applied to the disk was very, very, weak. To quote from the article, "Indeed, the bar is so low that even novice attackers will have no trouble getting over it." Another case of a potential poorly protected drive is one that is accessed via a fingerprint reader. Some of them use the fingerprint to generate an encryption key, others just use the key as a password substitute and don't actually encrypt the drive contents. I'm honestly a little bit suspicious over these devices, since I know how hard it can be to get a consistent read of a biometric property like a fingerprint or voiceprint. I am fairly certain that there is a *lot* of squish factor allowed in unlocking these devices -- otherwise they would be difficult to use. Other Problems With External Drives ----------------------------------------------------- Yet another one -- but I promise that this is the last one for this newsletter. Apple posted a KBase article about problems with mounting external drives. You need to make sure that your computer's name (in the Sharing prefs) is set and does not contain weird characters, and that the Time Machine prefs are set as well. --Paul Paul Suh http://www.ps-enable.com/ paul.suh@ps-enable.com (240) 672-4212 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2615 bytes Desc: not available Url : http://lists.ps-enable.com/pipermail/newsletter/attachments/20080305/3f0a965c/smime.bin From paul.suh at ps-enable.com Wed Mar 26 06:57:11 2008 From: paul.suh at ps-enable.com (Paul Suh) Date: Wed Mar 26 06:57:27 2008 Subject: [Newsletter] Misuse of NSLs, Tightening Up SSH Access, Disappearing Car Door Message-ID: <7F1F9DAA-1EF3-4DB7-9AB4-3948297467AC@ps-enable.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2615 bytes Desc: not available Url : http://lists.ps-enable.com/pipermail/newsletter/attachments/20080326/56b5873b/smime.bin