Friday, January 6, 2012

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.

StatusDMA Capture Result
Logged in, not lockedCaptured
Logged in, locked0s
Login, log out, at login screen0s
System booted, not logged in0s
Switch user from fast user switching menu0s

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

StatusDMA Capture Result
Logged in, not lockedCaptured
Logged in, lockedCaptured
Login, log out, at login screenCaptured
System booted, not logged inCaptured
Switch user from fast user switching menuCaptured

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.

9 comments:

_nico said...

Hello, thanks for the article, very interesting!

But, I still have a few questions:

- did you only test firewire, thunderbolt or both?
- did you modify kext-files?
- did you set a open-firmware password?
- did you try to get cleartext login-password, filevault-password or all passwords?

Thanks

G said...

1. firewire only, hope to play more with thunderbolt although there is very little information available about it.
2. No kext mods
3. No firmware password (see nvram security-mode post for more info)
4. Retrieved login password, which == filevault2 password.

TREMO said...

Hi, thanks for nice post.

Did you had chance to try it on windows? Are windows systems are still vulnerable?

Thanks.

G said...

Windows: read some of the papers on Uwe's site that I link to, including 'Subverting Windows 7 x64 Kernel with DMA Attacks'.

None said...

Thanks, great research!

Carsten said...

Hey guys - This may interest you: I can confirm that this attack works on OS X and Windows 7 - and also over the Thunderbolt interface:

http://www.breaknenter.org/2012/02/adventures-with-daisy-in-thunderbolt-dma-land-hacking-macs-through-the-thunderbolt-interface/

G said...

@Carsten: nice writeup. Summary for other readers: Carsten used a thunderbolt to firewire adapter, so the same defences apply (see his caveats section). It is the same firewire attack, just travelling over the thunderbolt interface.

Anonymous said...

Hi,
Is this hack also possible when the mac is set to require a password after a specified time after going to sleep?

So the question is, whether OS effectively locks down the machine after the specified time or if the lock down only takes effect when the machine wakes!?

Scenario would be: Lid is closed and the mac is set to require a password after 15 minutes. Someone steals the laptop after 30 minutes and tries to gain DMA control. Will DMA lock down appropriately or will I first have to lock the screen and then close the lid in order to not be vulnerable?

Cheers,
Anonymous

G said...

After 10.7.2, screen lock puts firewire into emulation mode, which protects against DMA attacks.