7 ms·
Inception: DMA Attack Against Linux, Windows, and Mac
- java-man 12y agoThis 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/src/goryachev/crypto/MemCrypt.java 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.
- teacup50 12y ago> 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.
- java-man 12y agoI 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.
- potatosareok 12y agoYou can disable paging if you really care about that but setting swapiness to 0. Or use something like https://github.com/LucidWorks/mlockall-agent https://github.com/LucidWorks/mlockall-agent
- sweis 12y agoYou 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 12y agoHow can you be sure data doesn't leave the cache if the kernel interrupts - or worse, the BIOS performs an SMM interrupt?
- sweis 12y agoYou 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.
- java-man 12y agoThere 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.
- sweis 12y agoYep, 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 https://www.youtube.com/watch?v=chvJpEmXvDk
- mjg59 12y agoCan you guarantee that the storage driver doesn't DMA your key material to RAM during initial boot?
- deleted 12y ago[deleted]
- comex 12y agoSince 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 12y agoIt'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 12y agoIsn'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 12y agoOnly 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.
- garrettr_ 12y agoI'm not familiar with the security benefits of VT-d; might you have a link to a whitepaper or another resource?
- wtallis 12y agoVT-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.
- deleted 12y ago[deleted]
- danesparza 12y agoThis is an impressive attack -- but as far as I can tell, it requires physical access to the machine. Is that correct?