

FileVault 2 Easily Decrypted - doublextremevil
http://reviews.cnet.com/8301-13727_7-57369983-263/filevault-2-easily-decrypted-warns-passware/

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

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

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

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

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

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

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

    
    
      sudo pmset -a hibernatemode 25 destroyfvkeyonstandby 1 sms 0

~~~
droithomme
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...](http://www.frameloss.org/2011/09/18/firewire-attacks-
against-mac-os-lion-filevault-2-encryption/)

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

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

------
nodata
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?

~~~
droithomme
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...](http://www.hermann-uwe.de/blog/physical-memory-attacks-via-firewire-
dma-part-1-overview-and-mitigation) \- 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.

~~~
kalleboo
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

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

------
fdb
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?

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

------
jvdh
Additional info is here:
[http://news.cnet.com/8301-1009_3-57370628-83/security-
concer...](http://news.cnet.com/8301-1009_3-57370628-83/security-concerns-on-
apples-filevault-decryption-via-firewire/)

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

~~~
pudquick
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!

------
aristidb
Infinite redirect chain on my mobile phone.

