Thunderbolt-DMA-land: Hacking Macs through the Thunderbolt interface

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

by fourk • 14 years ago

66 22 14 years ago

breaknenter.org

gergles• 14 years ago

You mean with someone with physical access to my machine can trivially bypass software security measures?

I am shocked, shocked, good sir!

feralchimp• 14 years ago

This attack is hot precisely bc it blurs the local/remote line.

Physical access is relative. 'Remote' vulns are still exploited with some level of physical access: i.e. via a network that lets you touch bits on the other side of the machine's ethernet jack / wireless card.

The other extreme is standing over the ripped carcass of the machine case, triumphantly raising an unencrypted hard disk over your head, and blowing a kiss to the receptionist on your way out through the main lobby.

The OP's attack can be staged multiple hops away, through a physical network of peripheral devices. In a heavy SAN or PPPoFW environment, where FW cables are regularly disappearing under desks, a somewhat-insider could dump a lot of RAM.

RAM which, for some goddamned reason on OS X, apparently contains an unencrypted copy of my login password?! Ouch.

ComputerGuru• 14 years ago

RAM which, for some goddamned reason on OS X, apparently contains an unencrypted copy of my login password?

Really? Most software does that, most crypto software and encryption algorithms are vulnerable to RAM attacks. It's not as easy to protect against that as you think it is.

wisty• 14 years ago

Better still - this is "plug into a compromised Thunderbolt monitor, and it can own the lower 4 Gigs of RAM on your machine".

Did I mention that Thunderbolt daisychains, so compromising a Thunderbolt monitor (or better still, projector) is a simple matter of plugging an attack machine into the Daisy-chain out port.

Who really worries about plugging their laptop into a projector?

somestuff• 14 years ago

"The other extreme is standing over the ripped carcass of the machine case, triumphantly raising an unencrypted hard disk over your head, and blowing a kiss to the receptionist on your way out through the main lobby."

Added to the bucket list.

chime• 14 years ago

You're presenting at a conference. You hook up your shiny new Macbook with Thunderbolt to the Thunderbolt-enabled projector and give a wonderful presentation. Unbeknownst to you, someone who had physical access to the projector and Inception software, now has a full dump of your RAM, including unencrypted passwords and keys.

If this was VGA or DVI, you have no reason to be suspicious. But with Thunderbolt, you can never be sure anymore.

X-Istence• 14 years ago

Feel free to remove the FW driver from the OS.

enneff• 14 years ago

I thought this was a hardware-based attack. Does it matter whether the OS supports firewire or not?

loeg• 14 years ago

No. It's direct DMA from the hardware.

jensnockert• 14 years ago

Without the driver, Firewire DMA is not enabled, so yes, it does matter. It is mentioned in the article.

Lion even disables Firewire DMA when the screen is locked if you are running Filevault, or if you have an EFI password.

Sanddancer3• 14 years ago

Yes it does matter, as the OS has to set up the DMA channels, etc.

rinkhals• 14 years ago

http://www.hermann-uwe.de/blog/physical-memory-attacks-via-f...

"We have successfully tested that after unloading AppleFWOHCI.kext the current tools won't work anymore."

If that's true then an option for those who need to use FW/TB devices is to remove the drivers from the system folder to prevent loading at startup and kextload/kextunload on demand.

The following named drivers are present in "/System/Library/Extensions/" :

IOFireWireAVC.kext IOFireWireFamily.kext //(The AppleFWOHCI.kext mentioned above is included here) IOFireWireIP.kext IOFireWireSBP2.kext IOFireWireSerialBusProtocolTransport.kext

IOThunderboltFamily.kext AppleThunderboltDPAdapters.kext AppleThunderboltEDMService.kext AppleThunderboltNHI.kext AppleThunderboltPCIAdapters.kext AppleThunderboltUTDM.kext

shaka881• 14 years ago

This is some serious shit. We're doomed!

Sanddancer3• 14 years ago

This is a deeper issue than just firewire. Yes, disabling firewire will stop this one vector of the attack, but there are plenty of other devices out there that can use DMA channels. I imagine someone halfway decent with vhdl and other languages can code an fpga that'll take the pci-e channel and enumerate as another device that the OS has DMA drivers for, like a SATA controller chipset or a sound card. From there, one has to implement just enough of the expected behaviors -- for a SATA controller, perhaps pretend to have a 1 meg drive attached to it, for example -- to get a DMA channel and continue as with the firewire attack.

The issue here is that Apple, like most OS vendors, still don't seem to use the IOMMU facilities built into chipsets, especially for untrusted devices, like anything connected to a thunderbolt port. Considering that the Firewire attack has been known for several years, it's rather foolish that a company would implement a spec that can provide direct access to RAM without such basic precautions.

justincormack• 14 years ago

SATA is not as straightforward, as far as I know there are no known attacks. It depends very much on the intface design, and you do not just get a pcie bus from sata. USB has some weak attacks apparently. Firewire and so on are mulimaster which is much more dangerous. No reason not to use iommu.

Sanddancer3• 14 years ago

SATA devices wouldn't be able to pull these off, but a malicious SATA /controller/, connected to the pci-e bus, could. There have been proof of concept rootkits ( http://www.livehacking.com/2010/11/23/backdoor-rootkit-for-n... ) which hack the firmware of devices to use the negotiated DMA channel for operating system corruption. I used SATA as an example because it's something that would not be as easy to disable. The firewire attack is easy to disable because it's well known and most people don't need firewire. SATA controllers are a lot more common and would require a lot more work to clean up.

__david__• 14 years ago

Apple actually had a remote debugger that (ab)used the FireWire DMA to get access to the RAM. I used it several times when debugging drivers on OS 9.

I had thought that the OS X FW drivers didn't map any RAM until a driver requested some 1394 address space, but apparently that isn't the case... That would be the sane and easy way to fix this.

sp332• 14 years ago

My favorite FW exploit story: someone thought their laptop was "secure" because it didn't even have a FW port. The attacker plugged in a FW card at the login prompt, and the OS automatically installed the drivers - and the vulnerability :)

zdw• 14 years ago

There are ways to prevent DMA over firewire, and also Apple has been aware of and provided prevention methods (such as disabling firewire DMA when a firmware password is enabled) over the years.

A good account of the current state of affairs is here:

http://derflounder.wordpress.com/2012/02/05/protecting-yours...

And a diagram of protection methods that do work:

http://www.frameloss.org/2011/09/18/firewire-attacks-against...

spitfire• 14 years ago

Funny, when I first heard about thunderbolt my first thought was "Cool, I can finally build my own SSI NUMA box like an SGI!".

The second thought was, gee, what if someone writes a crappy driver that scribbles another hosts memory.

Thunderbolt-DMA-land: Hacking Macs through the Thunderbolt interface

Related Stories