

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

======
Sanddancer
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
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.

~~~
Sanddancer
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...](http://www.livehacking.com/2010/11/23/backdoor-rootkit-for-network-
card/) ) 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.

------
zdw
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...](http://derflounder.wordpress.com/2012/02/05/protecting-yourself-
against-firewire-dma-attacks-on-10-7-x/)

And a diagram of protection methods that do work:

[http://www.frameloss.org/2011/09/18/firewire-attacks-
against...](http://www.frameloss.org/2011/09/18/firewire-attacks-against-mac-
os-lion-filevault-2-encryption/)

------
__david__
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
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 :)

------
X-Istence
Feel free to remove the FW driver from the OS.

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

~~~
loeg
No. It's direct DMA from the hardware.

~~~
calloc
It does matter. The OS has to set up the device for DMA in the first place. If
the device is never enumerated it just doesn't get access.

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

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

I am shocked, _shocked_ , good sir!

~~~
feralchimp
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
_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.

~~~
strictfp
Most software is vulnerable, but only for a very limited time span. If the
password is persistent in RAM during an entire session, it's still a WTF.

------
shaka881
This is some serious shit. We're doomed!

