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