Inception: DMA Attack Against Linux, Windows, and Mac | Hacker News Reader

Inception: DMA Attack Against Linux, Windows, and Mac

github.com

79 pointsdionyziz25 comments

Since I'm sure people will comment without reading it ;p, here is a copy of the Caveats section:

> OS X > 10.7.2 and Windows > 8.1 disables FireWire DMA when the user has locked the OS and thus prevents inception. The tool will still work while a user is logged on. However, this is a less probable attack scenario IRL.

> In addition, OS X Mavericks > 10.8.2 on Ivy Bridge (>= 2012 Macs) have enabled VT-D, effectively blocking DMA requests and thwarting all inception modules. Look for vtd[0] fault entries in your log/console.

It's a shame that Intel only advertises VT-d as an enterprise-oriented virtualization feature and only offers it on a few models of consumer CPUs. They should have treated it like the NX bit and made it universal so that operating systems could rely on it.

It's frankly disgusting that they are withholding an efficient hardware solution to an entire class of security problems, when they could make it available to almost everyone with a microcode update.

Isn't it on all the i5/i7 CPUs? I might be mistaken, but I can't recall a time in recent history I had a CPU without it.

Only the two most recent overclockable models (Devils Canyon variant of Haswell) have VT-d, and artificially excluding all the budget product lines is not a responsible way to handle what should be seen as a security feature first and foremost.

I'm not familiar with the security benefits of VT-d; might you have a link to a whitepaper or another resource?

VT-d is an I/O MMU: it does address space translation for DMA. In a virtualization scenario it enables DMA between real peripherals and virtual machines. In a security context it means you can control which parts of memory a malicious peripheral can DMA to, instead of granting it access to the full physical address space. In a more general OS driver context, it means that you don't have to worry about reserving low memory addresses for doing DMA with devices that only support 32-bit addressing.

Only the two most recent overclockable models (Devils Canyon variant of Haswell) have VT-d...

This means that previous *-K (multiplier-unlocked) models have VT-d disabled, right? So you have to choose between overclocking and VT-d.

Yes, although prior to Haswell it was still possible to do a moderate amount of overclocking on the non-K models that do have VT-d; the multiplier could be increased by about the same margin as the Turbo Boost feature uses, and you still got Turbo on top of that. Haswell marked a shift from a limited-unlocked multiplier to a fully-locked multiplier for the non-K parts.

Well, I doubt Intel sees it as a security feature first and foremost. But even if they did, they don't have an obligation to be "responsible" in how they market their features. Many of their pricing choices ultimately end up being related to yield. If they need to devote more transistors in order to enable an IOMMU, seems like it makes sense to charge more for it.

Core count, clock speed, and cache quantity are related to yield. HyperThreading, VT-d, AVX, Turbo Boost, AES-NI, TSX, and ECC are all too integral to the core design; they're physically present on all chips and it is extremely unlikely for a manufacturing defect to affect one of those features without otherwise crippling the chip. Those features are used for product segmentation that is not driven by any real marginal cost.

> But even if they did, they don't have an obligation to be "responsible" in how they market their features.

Intel is a corporation; its shareholders are shielded from personal financial liability for its errors; thus is seems appropriate that it be required to be responsible in exchange for the privileges it has been granted.

That's not what I see from searching Intel's ARK:

http://ark.intel.com/search/advanced

Here's a list of Intel's latest CPU series, and how many have VT-d support:

* 5th gen i7: 5/5

* 5th gen i5: 6/6

* 5th gen i3: 5/5

* 4th gen i7 extreme: 2/2

* 4th gen i7: 42/49

* 4th gen i5: 46/55

* 4th gen i3: 5/37

So the summary: all but the slowest gen 4 i5 and i7 chips have it, and all gen 5 chips currently released have it.

edit: formatting

For the purposes of this discussion, you really should be looking at more than just the current generation of chips, because the installed base that OS vendors have to worry about includes a lot of processors that are more than 18 months old, and a lot of processors from the budget product lines. The 5th generation parts so far are just ultra-low power tablet and ultrabook CPU, so almost all of the 4th-gen Haswell parts are still current.

Intel's been a lot better about including VT-d on laptop chips, especially recently, and haven't disabled it on the consumer rebrands of their server chips (the "i7 Extreme" parts) in the past few generations, but did on earlier generations. Among the desktop parts, they've been all over the place, and most notably all but two of their flagship overclockable desktop processors (-K models) have had it disabled. Those models have most likely outsold their i5 and i7 counterparts that do have VT-d, and probably themselves been cumulatively outsold by the i3, Pentium, and Celeron processors that also lack VT-d. A raw count of the model numbers shows that in the time since VT-d has been released, the desktop processor models have been split 134 to 63 in favor of not supporting it.

The overall picture is that VT-d support is at least as hit-or-miss as HyperThreading support, which the Steam Hardware Survey finds to be present on about two thirds of Intel machines. Motherboard firmware support for VT-d is even worse, and of those that do support it, it's usually off by default.

You're thinking of VT-x.

This attack is relevant for password storage apps.

As an additional countermeasure, I encrypt editor field and text area buffers that might contain sensitive information, see for example:

https://github.com/andy-goryachev/PasswordSafe/blob/master/s...

A symmetric key used to encrypt/decrypt RAM-based data is generated on the fly. There is a brief period in time when data is present in the clear in memory - when it's used - but nothing can be done about it, short of moving the code to some kind of protected processor.

> There is a brief period in time when data is present in the clear in memory - when it's used - but nothing can be done about it, short of moving the code to some kind of protected processor.

`mlock()` can be used to prevent the memory from being paged out, but the DMA issue itself isn't something that can be (or should be) solved in userspace; if someone can do DMA reads/writes, rewriting any code or data, there's nothing an application can do.

I agree, there should exists explicit OS mechanisms to prevent leakage, be it via DMA, paging, or any other way.

In the absence of such mechanisms, especially when mlock() is unavailable (if running a Java app, for example), the app designer can use tricks like one described above to increase the level of difficulty for an attacker. It is not a solution, but an additional countermeasure.

You can disable paging if you really care about that but setting swapiness to 0.

Or use something like https://github.com/LucidWorks/mlockall-agent

You don't need a "protected processor". At PrivateCore, we kept all key material pinned in the L3 cache and ensured it was never evicted to main memory.

Frozen Cache did something similar with No-Fill Mode.

Tresor used CPU debug registers.

How can you be sure data doesn't leave the cache if the kernel interrupts - or worse, the BIOS performs an SMM interrupt?

You modify the kernel. As for SMIs, you know where SMRAM is located in memory and the cache geometry, so can ensure that there are cache ways available which SMIs won't evict.

Cache evictions can also be monitored by CPU performance counters, so you can detect any that do occur.

There are cases when not only key material but also some data need to be protected.

For example, in a context of password storage app, the passwords and associated text should not remain in the clear in memory, and possibly even the character buffer of entry fields such as JPasswordField.

This is the reason for the MemCrypt code mentioned earlier.

Yep, we ran the entire Linux stack pinned in the L3 cache, so no data or code hit main memory which was not encrypted.

Ironically, we could test this by disabling VT-d and using a DMA device to read encrypted main memory. Here's an old demo video: https://www.youtube.com/watch?v=chvJpEmXvDk

Can you guarantee that the storage driver doesn't DMA your key material to RAM during initial boot?

This is an impressive attack -- but as far as I can tell, it requires physical access to the machine. Is that correct?

Reply on news.ycombinator.com