Live data from Hacker News

FileVault 2 Easily Decrypted

reviews.cnet.com

21–30 of 34 posts

Re: FileVault 2 Easily Decrypted

#21
post #2

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?

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…

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

Re: FileVault 2 Easily Decrypted

#22
post #21

Earlier quoted context omitted.

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…

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.

Re: FileVault 2 Easily Decrypted

#24
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.

Re: FileVault 2 Easily Decrypted

#25
post #3

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

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

Re: FileVault 2 Easily Decrypted

#26
post #4
post #3

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.

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.

Re: FileVault 2 Easily Decrypted

#27

Earlier quoted context omitted.

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…

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.

Re: FileVault 2 Easily Decrypted

#28
post #23

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...

Re: FileVault 2 Easily Decrypted

#29
post #18

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!

Re: FileVault 2 Easily Decrypted

#30

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 opt…

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.
Post reply on HN