
Inception: DMA Attack Against Linux, Windows, and Mac - dionyziz
https://github.com/carmaa/inception
======
comex
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.

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

~~~
mmastrac
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.

~~~
wtallis
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.

~~~
wyldfire
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.

~~~
wtallis
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.

------
java-man
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...](https://github.com/andy-
goryachev/PasswordSafe/blob/master/src/goryachev/crypto/MemCrypt.java)

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.

~~~
sweis
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.

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

~~~
sweis
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.

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

