Inception: DMA Attack Against Linux, Windows, and Mac

Since I&#x27;m sure people will comment without reading it ;p, here is a copy of the Caveats section:<p>&gt; OS X &gt; 10.7.2 and Windows &gt; 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.<p>&gt; In addition, OS X Mavericks &gt; 10.8.2 on Ivy Bridge (&gt;= 2012 Macs) have enabled VT-D, effectively blocking DMA requests and thwarting all inception modules. Look for vtd[0] fault entries in your log&#x2F;console.

It&#x27;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.<p>It&#x27;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.

This attack is relevant for password storage apps.<p>As an additional countermeasure, I encrypt editor field and text area buffers that might contain sensitive information, see for example:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;andy-goryachev&#x2F;PasswordSafe&#x2F;blob&#x2F;master&#x2F;src&#x2F;goryachev&#x2F;crypto&#x2F;MemCrypt.java" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;andy-goryachev&#x2F;PasswordSafe&#x2F;blob&#x2F;master&#x2F;s...</a><p>A symmetric key used to encrypt&#x2F;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&#x27;s used - but nothing can be done about it, short of moving the code to some kind of protected processor.

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