It seems like the root problem here, as in lots of security problems, is an assumption made early on is no longer valid (e.g. "this application only runs on our LAN, so no need to protect against malicious actors"). In this case, PCI was originally an internal technology -- adding a new PCI device involved opening the case and plugging in a new card. Pluggable PCIe devices changed that assumption, so things that were previously pretty safe (trusting a new piece of hardware physically installed into the box) became unsafe (trusting a random device plugged into the box).
This part was especially interesting:<p><i>Q: Isn’t FireWire a dying horse? Few laptops ship with FireWire ports these days, which makes Inception a useless tool.<p>A: You can use any interface that expands the PCIe bus, for example PCMCIA, ExpressCards, the new Thunderbolt interface and perhaps SD/IO to hotplug a FireWire interface into the victim machine. The OS will install the necessary drivers on the fly, even when the machine is locked.</i>
Note that on newer processors, VT-d is supposed to entirely prevent this attack on CPUs that support it (damn Intel), and OSes do use it [1]. I'm curious whether anyone has tried to search for bugs in those implementations.<p>[1] <a href="https://developer.apple.com/library/mac/documentation/HardwareDrivers/Conceptual/ThunderboltDevGuide/DebuggingThunderboltDrivers/DebuggingThunderboltDrivers.html" rel="nofollow">https://developer.apple.com/library/mac/documentation/Hardwa...</a>
Wait, firewire devices are allowed to write to any address in memory they like to? How ridiculous is that? Why is there no memory protection?<p>I wonder how to block this... It seems like it can only write to the lower 4 GB... RAM is cheap... so add an addtional 4 GB and then modify the kernel to load everything critical above the boundary?
While this attack is a bit old, the proofs of concept remain, except you can do more fun things with certain hardware released in the interim. For example, Apple's firewire display uses a broadcom networking chip that is susceptable to people writing malicious firmware for -- <a href="http://esec-lab.sogeti.com/post/2010/11/21/Presentation-at-Hack.lu-%3A-Reversing-the-Broacom-NetExtreme-s-firmware" rel="nofollow">http://esec-lab.sogeti.com/post/2010/11/21/Presentation-at-H...</a> . Fitting a malicious payload into the given space may be a bit tough, but I imagine the intrepid hacker can do it with style and flare.
Couple of caveats. Many Laptops have Firewire ports that are attached via USB for cost reasons. These 1394 ports will do DV, and attached storage but are not DMA.<p>Thunderbolt on Windows 8 has an option for Allow DMA by Default, or not. This option is so that you can do a bit more prioritizing of your bandwidth.<p>Windows 8 also has a setting for "install new hardware automatically" which if you disable you can only install hardware if you are logged in and click the install button.<p>Windows 8 will also not allow you to install a new device if you are not logged in as Admin, or you have the Annoying UAC enabled.<p>So while Mac and some Linux systems will have this vulnerability because you don't have to be an admin to have new hardware enabled if the drivers are on the system, Windows should be safe unless you changed your rights.<p>On a corporate network with machines where the users run in least user privilege, Windows 8, and Windows 7 users are safe.
> Don’t panic – if you are using FileVault2 and OS X Lion (10.7.2) and higher, the OS will automatically turn off DMA when locked – you’re still vulnerable to attacks when unlocked, though<p>So, not really a problem then?
0. Is there a way to disable FireWire and Thunderbolt ports on OSX?<p>1. Is there yet any I/O firewall like Little Snitch or Hands Off! are for files and network?<p>2. Linux and Windows also desperately need I/O firewalls.
<i>OS X: Don’t panic – if you are using FileVault2 and OS X Lion (10.7.2) and higher, the OS will automatically turn off DMA when locked – you’re still vulnerable to attacks when unlocked, though</i><p>Phew.