FileVault 2 Easily Decrypted | Hacker News Reader

FileVault 2 Easily Decrypted

reviews.cnet.com

Current Linux disables the device-initiated DMA mechanism for firewire and other "untrusted" busses, though it should probably consider more types of busses "untrusted" than it does. This requires the host driver to initiate DMA, which it'll only do for devices it knows how to talk to safely. Turning this protection off (and thus making the system insecure) requires both compiling a kernel with the debugging-only option CONFIG_FIREWIRE_OHCI_REMOTE_DMA turned on and passing a kernel parameter at boot time, so you can't do it accidentally.

I thought more recent versions of OS X fixed this problem as well, but perhaps not.

FireWire and Thunderbolt DMA is disabled if you set an firmware password. On systems which support Intel's VT-d technology, the OS will actually allow restricted DMA even with the firmware password set so you get almost all the benefits of DMA without the security compromise of having all memory exposed to the foreign device.

This is a great article about this subject:

http://www.hermann-uwe.de/blog/physical-memory-attacks-via-f...

It contains mitigation information for OSX, Linux, Windows and various flavours of Unix.

Actually this applies to "all" other similar encryption technologies and is not limited to mac or firewire. You can also use Thunderbolt, PCMCIA, ExpressCard and even esata ports to have direct access to a computers RAM in which you passphrase is being held.

Basically all ports which use DMA are possible if I remember correctly.

Further reading:

http://en.wikipedia.org/wiki/DMA_attack

Basically the only "defense" is to shut your computer down when you're leaving it alone / unattended for some time.

Turning off the machine can be easily socially engineered around by a determined targeted attacker; all from fire alarms to a visit from IT staff to giving you a free memory stick at a trade show and so on. If you were to be gifted a new USB keyboard tomorrow from some random company, you'd likely accept it unquestioningly.

Also, given that you leave your computer unattended, even whilst turned off, gives the attacker opportunity to insert a small device out of sight, rather as cleaners really have done with keyloggers on computers at banks.

Isn't when you are present the time when its hardest for them to attack because of the physical contact required?

Of course, in films the robber-dressed-as-janitor always manages to walk into the server-room with a tool box..

There are three types of attacker, right?

1) your password/data is valuable, its a targeted attack, the attacker will take the risk of direct access to the machine; they can do this by socially engineering you to insert the trojan hardware, or they can add some small hardware dongle when you don't see or understand

2) law enforcement, they will grab the machine, you'll know they have done so; DMA attack is just a lot more straightforward than freezing it and probing type attacks.

3) those prepared to use a $5 wrench http://xkcd.com/538/

Why won't disabling features which give easy access to ram work?

It would have to be disabling by omission.

I've seen dumb terminals for military networks that simply don't have any slots for any peripherals.

Which means staff go to great lengths to work around these limitations and basically open everything up and email documents to their hotmail account so they can print them off elsewhere etc.

Because the point of DMA is to give fast access to RAM without involving the CPU. That is what makes the speed of Firewire or PCMCIA or Thunderbolt or PCIE feasible. Without DMA, these technologies would not work.

Also, the password needs to be stored in memory and accessible by DMA, since you would not be able to use it without having it readily available.

I thought things had been like this for a while now. A year ago Wired magazine had a good article about a guy who ran a site buying and selling credit card details and law enforcements attempts to catch him.

The computer had full disk encryption which they couldn't touch. Instead they needed to raid the guys house when the computer was on and secure it so the techs could pull what they needed from memory.

I didn't think it could be done in under an hour though.

Actually, the "standard" solution is epoxy ("glue"). ;-)

It should be mentioned that in the past the University of Princeton had successfully extracted encryption keys from a cold booted computer after the PC has been completely turned off.

They even demonstrate what they had recovered and how many bits has been lost.

Check this page and videos: https://citp.princeton.edu/research/memory/ https://citp.princeton.edu/research/memory/media/

I use suspend-to-disk which suspends to my encryped swap partition. No need to "shut down" your computer, just don't use suspend-to-ram.

There are certainly other defenses.

I patched my kernel with TRESOR, so the key for my full disk encryption lives in the debug registers of my CPU and stays out of RAM. The encryption operations are all performed directly on the CPU utilising its AES-NI instructions.

So even if you manage to read my RAM, you wont get my full disk encryption key. I wrote up how I did this (and loads of other things) at https://grepular.com/Protecting_a_Laptop_from_Simple_and_Sop...

EDIT: Of course, my RAM may contain other compromising data than my encryption key. So yes, I do shut it down when it's not attended, and have disabled firewire etc. Lots of details about other things I've done are at that blog post.

You are sure you can do remote DMA with eSATA? I've always thought Firewire was the only consumer product doing it.

This is what I set on my MBP (equipped with SSD):

  sudo pmset -a hibernatemode 25 destroyfvkeyonstandby 1 sms 0

Thanks, that is very useful, I was wondering why it didn't scrub it from memory when it sleeps.

Article discussing this setting and providing links to a free and open forensic library so people can actually test the FW memory search method themselves, yanking passwords straight off of their friends laptops as a fun party trick or what not: http://www.frameloss.org/2011/09/18/firewire-attacks-against...

It's not scrubbed from memory on short term sleep so the OS can provide a more user friendly experience – rather than dropping you at the EFI login window when you wake from sleep, you'll be presented with the more capable and better looking OS sleep unlock window.

If the machine is asleep for "a while" then it will write out a sleep image file and power off RAM (and other hardware) to go into a deep sleep. Since the sleep image file is written to the FDE volume, you must first unlock the volume at EFI's login window to gain access to the sleep image and resume from sleep. That process takes far longer than waking from a warm OS, so it's not done by default. You can change sleep settings using pmset on the command line and force it to always destroy the FV keys on sleep, if security is more important that a quick wake from sleep.

Yes, I switched the pmset settings after reading the article I linked to that discussed his settings and making the comment.

Benchmarking it shows that with all programs quit and hibernatemode at 25, it takes around 2 seconds to enter RAM-off-sleep and 8 seconds to awaken from it, rather than both happening instantly with RAM-on-sleep. It's not really all that slow, I wouldn't say it's all that noticeably longer. It's kind of an impressively fast memory dump and restore.

tl;dr: direct memory access via firewire can recover the key within an hour.

Anyone know if firewire be disabled at the hardware level on macs?

I was going to suggest filling the socket with dried play-doh, but thus guy reckons removing the kernel extensions could help:

https://discussions.apple.com/message/9200953#9200953

Though that's a bit crude...

I'd be interested too.

It's not really scanning memory, that's just their marketers trying to spin some razzlemadazzle for the plebes.

It's using Firewire Target Disk mode to get raw access to the disk. Apple stores its admin passwords using the highly obsolete MD5 algorithm, which is easily cracked in most cases using rainbow tables generated using the seed that is stored in plain text. It's pretty simply and I have personally broke into my own File Vault partitions after forgetting the password. You don't even need to spent $995, it's trivial to do with almost no skills. Anyone can do it themselves, which should convince them that File Vault is useless and its CPU load a pointless price to pay for zero security gain. This has all been dead obvious from day one too, the cited article is not even news, it's an advertisement for a company selling junk to clueless law enforcement incapable of doing basic research.

edit: OK, I'm wrong on some technical details:

1. Apple uses SHA-1 hashing not MD5.

2. I either need admin access in any account to access the /private/var/db/dslocal/nodes/Default/users/ folder and pull the plist with the hash from the account I am interested in, or I need to boot in Firewire mode which allows raw disk access to the unencrypted partition with that folder. (I haven't paid $995 for the referenced program but that would seem possible that's what it is really doing, not reading memory through FireWire looking for the plaintext password stored in the open in memory, which is also possible: http://www.hermann-uwe.de/blog/physical-memory-attacks-via-f... - this also helpfully notes that "sudo kextunload /System/Library/Extensions/IOFireWireFamily.kext/Contents/PlugIns/AppleFWOHCI.kext" deletes the relevant kernel extension to kill FW - I happen to already have this removed for other reasons.)

Still just as vulnerable to rainbow tables, but shoot maybe it does scan memory.

Wouldn't Firewire Target Disk mode just give them the encrypted data, i.e. useless? The admin passwords are stored on the encrypted partition.

edit: I guess your edits deprecate my reply

Yes, the admin password hashes have to be stored unencrypted otherwise you can't log in at all.

So, you kinda made the part up about personally breaking then?

No I didn't make it up, I have recovered passwords on encrypted volumes just as I said, and just as you can. It's been a few months since I last had to do this. After posting I realized I was unsure if the hashing algorithm was really MD5, went and looked at the actual hash after posting to make sure that I had it right, saw that it's SHA-1 not MD5, and appended the post with a prominently noted edit so it would be clear I wasn't trying to hide anything retroactively through edits.

edit: It's foolish downvoting these two posts. The information is factual. I corrected my error about the hash. Both MD5 and SHA-1 are vulnerable to rainbow tables folks. To fix the rainbow attack Apple should be using Two Fish instead of SHA-1 which is highly susceptible to this attack, which is why I was able to recover my password. If you can recover your password, you don't have security. Attempting to do so is a good exercise in finding out if you have security, at least it was for me and I now use much better admin passwords, though the better solution would be for Apple to upgrade to a much more resilient hash for passwords.

Or they could salt the password hash with the username. Rainbow tables would need to be based on the salt and therefore unlikely to exist.

Since the MacBook Air doesn't have a FireWire port, can I assume this technique doesn't apply? Or would it still be possible using one of the other ports?

The thunderbolt port have DMA access also, so I suppose the technique applies as well.

Additional info is here: http://news.cnet.com/8301-1009_3-57370628-83/security-concer...

On PPC Macs with Open Firmware (pre-EFI), FireWire DMA would be disabled if a boot password was set. I haven't come across any details on recent models...

Works for Intel / EFI as well.

Setting a boot password will lock out boot media / FireWire DMA.

You can set it from your install media's Utilities menu (or while booted into Lion Recovery Partition).

Fun fact: All of the Open Firmware / PPC Macs and most of the Intel Macs (with the exception of most every 2010+ model) could reset or blank the password by changing the RAM configuration.

The newest Intel Macs, however, won't do this. You have to take the Mac to a service center where they generate a special binary (using an internal tool) that's specific to the machine(s) they need to unlock and place it on USB media, during boot, to trigger an unlock override.

In short: Got a new new Mac? Don't set a password and forget it, write it down!

Infinite redirect chain on my mobile phone.

Reply on news.ycombinator.com