Apple and Intel have introduced a new notebook connection technology called Thunderbolt that will hopefully replace all the other cables coming out of your laptop. However, it appears to share the same security flaw as some of these older technologies: attaching a hostile device can break into your computer. A hacker can walk up to your laptop while you are not looking, connect a device for a few seconds, disconnect it and walk away with your data (such as passwords). This works even when your laptop is "locked" with the password screen. We can't prove this until we get our hands on the hardware, but all signs point to hackers being able to exploit Thunderbolt.
Imagine that you are at a conference. You innocently attach your DisplayPort to a projector to show your presentation on the big screen. Unknown to you, while giving your presentation, the projector is downloading the entire contents of your hard disk.
The reason this works is the trusting nature of the protocol. Your laptop sends a command across the wire saying "please write the data in my memory location XYZ". What the device on the other end is then supposed to do is send the data with an address of XYZ. But it does't have to. It can instead send data to address ABC. In other words, it can upload malware into the computer's memory and run it.
This technique rarely works on USB. That's because USB is designed in a "master-slave" configuration. Your computer can do this trick against anything attached to your USB port. Indeed, that's how some "jailbreaking" of devices like iPhone's work. Your computer, the master, infects the phone with malware by writing to specific locations in the phone's memory.
However, in some versions of USB (such as USB On-the-Go), the devices will negotiate who is to be master, and who is to be slave. We found a couple notebooks 6 years ago that could be broken into with USB this way. I don't know if any newer computers can.
But most other technologies are "peer-to-peer" rather than "master-slave". In those cases, either side can hack into the other. We did this at a pentest recently. A company gave employees laptops that were secured using all the latest technology, such as encrypted boot disks and disabled USB ports. Users weren't given admin privileges. But the Firewire ports were open. We connected a device to the Firewire port on a laptop, and broke in with administrator access. Once in, we grabbed the encrypted administrator password (the one the owner of the laptop didn't know). We cracked it using L0phtcrack. That password was the same for all notebooks handed out by the company, so we now could log onto anybody's notebook. Worse -- that administrator account was also on their servers, so we could simply log into their domain controllers using that account and take control of the entire enterprise.
Another real-world story comes from the HBGary e-mails. Apparently, HBGary sold devices to the government so that they could perform the same sort of trick. We did it with a laptop running Linux, but you can easily do this from a thumbdrive.
The current Thunderbolt simply sends PCIe signals across the wire. That means, in theory, anything a PCIe card can do, a Thunderbolt device can do. A hostile device should be able to send any address it wants, to read and write any part of memory of the host machine.
Intel has a solution for this. It's called "Intel Virtualization Technology for Directed I/O" or "VT-d". Using VT-d, a driver can configure the chipset to allow a device on the PCIe bus (or the Thunderbolt connection) to only write to specific areas of memory instead of the entire memory. The processors in the MacBooks support this feature, but Mac OS X does not (at least, last time I checked it wasn't).
Note that MacBooks already have Firewire, ExpressCard, and SD/IO ports that are vulnerable to this feature. Therefore, having yet another port with the same vulnerability isn't a huge increase in the risk.
Update: iFixit's teardown shows that the MacBook uses the BD82HM65 southbridge, which does not support Vt-d.
8 comments:
It's called an IOMMU (http://en.wikipedia.org/wiki/IOMMU)
This has been in most processors since 2006/2007.
yeah, forgetting to lock your desktop while taking a piss results in such comments, kudos to my colleagues
When you enable a firmware password on a Mac this "feature" of Firewire is disabled and it goes into lockdown mode ...
Given that statement of X-Istence, you guys should test that out as well.
It's a bit silly to write an article about theorized security flaws without actually exploiting them, that presents a particular bias in the article - perhaps just to stir up debate/intelligent conversation - but we need real data here if your argument's to hold any water, just sayin'.
Also I don't think security was a big issue until people started this "data mining" hysteria, FW was developed in the 80's after all, but it's a dying horse..
Test Thunderbolt without the chip, then test another computer with said chip. Test both systems locked via EFI, then test them without being in lockdown mode. This should remove your bias, and the result will actually be accurate (or should be, but now I'm theorizing myself here). Also test with systems 100% locked-down vs. not. There are many variables to the equation you see :) Just sayin'
This article presents a particular bias since there is no real-world evidence to back up your claim (we need data).
Test the hardware locked down, perhaps you could take X-Istence's statement further by doing so to remove any bias in your article.
Test a computer without that said chip, and test one with it. Then test both systems completely locked down (EFI password+lockdown et al). And test without EFI locks.
FireWire was developed in the 80's, I don't think security was a concern till this data mining hysteria started, just my opinion.
I conduct research in the field of FireWire (IEEE 1394) memory forensics and can confirm that on Mac OS X a firmware password disables DMA.
However, if Thunderbolt just pipes PCI-type signals over a bus then a firmware password will not be effective. The firmware password technique only works because the OHCI has a register for enabling/disabling physical requests.
For those that are interested my thesis can be found on my website:
https://freddie.witherden.org/pages/ieee-1394-forensics/
The correct solution -- albeit a hardware one -- to this problem is to stick an IOMMU between the Thunderbold controller and the memory controller.
Turns out that this works as advertised: http://www.breaknenter.org/2012/02/adventures-with-daisy-in-thunderbolt-dma-land-hacking-macs-through-the-thunderbolt-interface/
Great job!!! Yeah, forgetting to lock your desktop while taking a piss results in such comments, kudos to my colleagues
Post a Comment