Inception - Root any machine over FireWire, Thunderbolt, others | Hacker News Reader

Inception - Root any machine over FireWire, Thunderbolt, others

breaknenter.org

125 pointsrdn62 comments

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

It's not even that - well, maybe a little bit that, but all pieces of hardware with independent processors could theoretically own your machine. (Even, theoretically, pieces of hardware that attach to your machine that only emulate simple state machines could hijack your CPU and make a "weird machine".)

The problem here is fundamentally one of performance - PCIe and other devices cannot function efficiently without direct memory access. The only reason FireWire was capable of the speeds it originally was, was because of DMA. USB didn't have DMA (and still doesn't? I think..) and so for shuttling large amounts of uncompressed data into the address space of a consuming application, it was incredibly inefficient to involve the CPU.

PCI-Express and other buses followed a similar route - DMA is vastly superior to every other way of transferring data.

Theoretically an I/O memory management unit with virtualization support could protect your machine, but I don't know if any OSes and hardware combinations actually use that to protect the machine.

The problem is not in DMA. The problem is that DMA is allowed across memory protection, without authorization and without user consent.

I suppose it made sense when Macs and PCs ran single-user OSes on hardware that lacked memory protection. Keeping the default behavior from that day is not wise for, well, last decade or so. (Fresh OSX seems to have changed accordingly, as the tool's page mentions.)

You mean the problem with Direct Memory Access is that it's Direct? Memory protection, authorization checks, and user consent are all implemented by the CPU knowing which pieces of memory are what. If you use DMA you're just writing to and reading from specific locations on the RAM chips, irrespective of what the CPU wants you to do. RAM chips don't have ACLs; They'll do whatever requests hit their pins.

The IOMMU is basically ACLs for RAM, but OSes don't use it as much as they could (possibly because Intel disables it on random SKUs).

It's really easy to have direct access to a single range of memory and no access outside of that range. It's also really easy to have somewhat more complicated schemes. There is nothing inherently insecure about DMA. It's just shoddy protocols and/or protocols used in unexpected ways.

This is another of those "people did it 100 years ago and now we have to reinvent it" things. The Mark I would never have had this problem.

There's a handshake that's done with the PCIe device; It doesn't cost anything to keep the address/data lines off until the handshake is complete, and require that the user approve the handshake.

True, this will not stop an e.g. accepted external drive from DMAing - but it will stop a randomly plugged thing from doing so.

Not having this level is worse than Windows' of old tendency to autorun anything called "autorun.inf" on a media - because autorun was still subject to user privileges whereas the PCIe "autorun" is not.

I don't see the concept of DMA as unsafe. I'm not that familiar with x86, but it seems that random devices can set up DMA transfers. Why? I guess there were performance considerations, but in that case an IOMMU needs to be used. On the systems I've worked on, only the CPU can set up DMA transactions (which includes transfer length, source and destination), which should prevent trivial attacks.

One advantage of bus mastering, at least in theory, is that you can do peer-to-peer transfers without going through main system memory.

In practice, I don't think this works out too well for really heavy workloads... both NVIDIA SLI and AMD Crossfire require their own interconnects, presumably because of limited bus bandwidth.

Remember the days when you had a separate MPEG-2 decoder card that externally proxied VGA from your graphics card?

Microsoft, at least, was thinking about this and trying to mitigate as early as 2003 [1],

Attacks over FireWire or SCSI were part of the threat model that the Palladium team was concerned about.

[1] http://www.google.com/patents/US7975117

This part was especially interesting:

Q: Isn’t FireWire a dying horse? Few laptops ship with FireWire ports these days, which makes Inception a useless tool.

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.

But this also has a positive side:

Ensure that FireWire drivers are present and not removed from the system

In other words, if you don't have FireWire drivers installed, then this won't do anything; another plus for not installing the drivers for those who have a system with FireWire ports but never need to use them.

My laptop has both FireWire and USB controllers disabled, the former because I never use it and the latter because I almost never use it - and when I do, I find it's not too much hassle to go into the Device Manager and enable the one for the one port I intend to use. Another positive side-effect is that the USB drivers seem to take a rather long time to initialise, so booting is much faster without them.

I don't think this kind of attack is limited to FireWire; that was just the easiest version to build. Thunderbolt can attach arbitrary PCI devices, like an FPGA that pretends to be an AHCI controller...

These interfaces have DMA, they don't need drivers to interface with the hardware.

They do need a driver to set up which DMA channel to use, etc. While these devices can go nuts once things are up and running, just plugging it in won't do anything until the computer actually acknowledges it.

So, for example, if one builds a custom Linux kernel without support for Firewire, then plugging in a firewire controller would do nothing? It couldn't access anything?

Exactly. A PCI(e) device needs to ask things of the kernel for it to initialize. Until it gets that info, it's just a motherboard warmer.

It can still read and write to memory. If it needs to "initialize" anything, it will have to commandeer the CPU by creatively rewriting memory that is in use.

This would be possible with regular PCI which is bus-based, but PCIe is a star topology with ports on the upstream switch needing to be configured into an active state for the newly plugged in device to communicate with the rest of the system. I haven't looked at the specifications but I imagine it's the same for Thunderbolt - the controller itself has to be enabled first.

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.

[1] https://developer.apple.com/library/mac/documentation/Hardwa...

It's worse than that. The processor might support VT-d, but your motherboard chipset also has to support it. Even then, you might get a BIOS that doesn't expose the necessary information. All of these things are subject to market segmentation and other such unpleasantness.

In the end, unless you can coerce a DMAR table out of the machine, I'm not sure how you can tell if the thing actually supports VT-d.

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?

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?

The fix is to fill the FireWire port with rubber cement.

May be effective against casual industrial espionage, but it’s a fat lot of good that’s going to do if your computer was seized. It can’t be hard for a forensics lab to get around that particular defense!

http://www.youtube.com/watch?v=ynzcUw9wv0E#t=18 (where rubber cement is the leaf. just go around it!)

Nothing exciting here... if you have physical access, it's game over.

Isn't there a practical distinction though between having your computer compromised when you turn your back on someone for 5 seconds and when you leave them alone with your computer for a few minutes?

I asked about this just the other day because I use full-disk encryption, but rarely shut the machine down (just sleep with screen lock). The responder was fairly confident that this was not a concern, but Inception does not require an implausible level of expertise to use, yet it would render my encryption useless (assuming the driver is present).

https://news.ycombinator.com/item?id=7113788

A couple years ago, I chased down and tackled a guy who snatched my laptop on the Blue Line in Chicago. The threat of laptop theft is real and I'd like to mitigate the damage that would result without compromising my ability to work.

On OSX, IIRC, FireWire DMA was disabled if full disk encryption is turned on. Windows similarly has some sort of security advisory or capability wrt FireWire.

If other ports are exposed that offer DMA capabilities, then they need to be disabled. Don't load the drivers/epoxy the physical ports.

I was not aware that a new connector would reopen such a massive vulnerability. (Docking ports may also have some issue, but since they're proprietary it wouldn't matter.)

That said, I think my assessment is still accurate. If you're just worried about a theft, it seems very unlikely they'd run these kinds of tools before restarting. And even then, why bother? Why not just reformat the machine, if it's just a theft? If you have actual enemies "then keep your laptop physically secured and powered off. And don't use it after breaking chain of custody."

The really shitty thing is that some new laptops (W540) apparently don't ship DisplayPort or other digital video, but just Thunderbolt.

What's even niftier is, say with Windows and BitLocker, the BitLocker key can be recovered from a memory dump pulled this way. Couple this with live patching of RAM to bypass the lock screen and you're just kinda sunk.

And yes, me, a not particularly security-oriented guy, did this fairly quickly as a demonstration for coworkers. It required only marginally more than script kiddie levels of knowledge.

On Mac you can get the encryption key from RAM too, though if you turn on some settings, you can force the Mac to attempt a shutdown when it sleeps, clearing the encryption key until you enter your password later. There's still a DMA leak at startup also, but securing the EFI firmware helps keep things locked down. There was an article on HN recently with step by step instructions on scanning memory for things that look like AES keys when using TrueCrypt.

I suspect without a Yubikey or Microsoft TPM, effectively storing the key outside of RAM, there's not much that can be done to fight this. And of course, physical access means you've got the TPM or Yubikey in front of you. And unencrypted data in RAM. So.... Yeah.

Actually, there are solutions to store the keys in CPU privileged registers (eg: hw debug registers), and when combined with AES-NI don't even cause much overhead: http://en.m.wikipedia.org/wiki/TRESOR

Not sure why these techniques aren't mainstream yet.

Even without this type of PCI attack, you still have to worry about a cold boot attack. This is were the attacker quickly power-cycles the computer to boot into another OS (or special purpose boot code), and performs a memory dump. Often times the power cycles quickly enough that useful amounts of data remain in the RAM. This attack can be made more effective if you can get physical access to the RAM and cool it.

As most (if not all) disk encryption programs store an expanded version of the key in memory, there is significant redundancy to recover from the partially lost data.

>This is were the attacker quickly power-cycles the computer to boot into another OS (or special purpose boot code), and performs a memory dump. Often times the power cycles quickly enough that useful amounts of data remain in the RAM. This attack can be made more effective if you can get physical access to the RAM and cool it.

Has anybody ever did this to someone?

Outside of Bond movies?

https://citp.princeton.edu/research/memory/

A few years ago, I tried this on my own laptop. I didn't have any sort of full disk encryption to test against, so I simply checked the RAM dump for plaintext looking things. Without having cooled the RAM (or opened the computer at all), there was a significant amount of meaningful plain-text. If you are interested in actual data about how effective this is, you should probably ignore my antecedent and look at the research paper in the above link.

Given how easy this attack is for its effectiveness, I would be suprised if it is not used.

It has been demonstrated publicly.

http://www.youtube.com/watch?v=Y_70UC0tPUU

You should always hibernate to crypted partition, when you are away from you computer. With modern SSD it's fast.

You should never leave a sensitive device like your laptop unattended. A sophisticated attacker can replace your bootloader with a backdoored version that stores the encryption paraphrase to disk in plain.

That's what safe boot is for. You can't do this on a chrome book or a windows 8 laptop which is safe boot locked.

Cool. Lets all disable password protection on our machines and leave them unlocked. Apparently if you have physical access, it's game over so there's no point in even trying.

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 -- http://esec-lab.sogeti.com/post/2010/11/21/Presentation-at-H... . 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.

(2011) should be added to the title; see the date of the comments below the article.

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.

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.

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.

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.

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.

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

So, not really a problem then?

Imagine a Thunderbolt display on a desk. The attacker builds a small box that plugs into the firewire port on the back and exposes the port over wifi (or runs a prewritten script). The target plugs in their computer to work and is rooted.

Instead of that, I would sniff a supplied keyboard instead.

This is relatively old. I first recall seeing it a few years ago.

If so, why haven't Microsoft and Apple patched it?

It's part of the FireWire spec, they can't.

It has nothing to do with the firewire spec.

It's perfectly reasonable (if technically possible) for either the OS or a third-party "firewall" app to intercept dangerous requests and prompt the user to allow/deny them.

It isn't a software issue - it's a hardware issue. FireWire and these other specifications require direct memory access. If you plug in a device and it emulates something that requests DMA from the hardware, your machine can be owned.

The solution is an IO memory management unit with virtualized access to physical memory. I am not sure how you can actually enforce this to devices on the bus though.

If it requires a driver (and it does), it is a software issue. Just having a FireWire port, without a driver, is not enough.

So a sane OS should just not allow to initialize a DMA transfer from a newly attached device until a user with enough privilege allows it.

The solution is easier than that: only open up the appropriate buffers to DMA. It doesn't need to be virtualized, it just needs to be bounds checked.

Maybe I'm spoiled by good hardware, but when I wrote FireWire drivers for embedded systems, we didn't just open up DMA access to RAM willy-nilly.

I honestly don't know enough about OHCI to know what the hardware setup is like, but I suspect it's just laziness.

OSX 10.7.2+ apparently disables DMA when using FileVault and a screen lock. See the article 'Attack mitigation - OSX'. Seems like a decent compromise.

See for instance:

http://support.microsoft.com/kb/2516445

It's a well known limitation/tradeoff. Newer machines might ditch DisplayPort for Thunderbolt, which will really suck.

"The drawback of this mitigation is that external storage devices can no longer connect by using the 1394 port, and all PCI Express devices that are connected to the Thunderbolt port will not work. Because USB and eSATA are so prevalent, and because DisplayPort often works even when Thunderbolt is disabled, the adverse effect caused by these mitigations should be limited. "

From the article:

> Attack Mitigation : OSX : 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

So it sounds like Apple has patched it. You just have to make sure your machine is locked.

On Windows there's no patching to do, since this is by design. If you want to close this potential hole you simply stop the Firewire DMA driver from loading, which is pretty easy to do via Group or Local Policy. Microsoft has an article on it here: http://support.microsoft.com/kb/2516445

0. Is there a way to disable FireWire and Thunderbolt ports on OSX?

1. Is there yet any I/O firewall like Little Snitch or Hands Off! are for files and network?

2. Linux and Windows also desperately need I/O firewalls.

http://www.hermann-uwe.de/blog/physical-memory-attacks-via-f...

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

Phew.

Awesome work, loved thr name

Reply on news.ycombinator.com