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.<p>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.
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.<p>A good account of the current state of affairs is here:<p><a href="http://derflounder.wordpress.com/2012/02/05/protecting-yourself-against-firewire-dma-attacks-on-10-7-x/" rel="nofollow">http://derflounder.wordpress.com/2012/02/05/protecting-yours...</a><p>And a diagram of protection methods that do work:<p><a href="http://www.frameloss.org/2011/09/18/firewire-attacks-against-mac-os-lion-filevault-2-encryption/" rel="nofollow">http://www.frameloss.org/2011/09/18/firewire-attacks-against...</a>
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.<p>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.
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 :)
Funny, when I first heard about thunderbolt my first thought was "Cool, I can finally build my own SSI NUMA box like an SGI!".<p>The second thought was, gee, what if someone writes a crappy driver that scribbles another hosts memory.