Inception: DMA Attack Against Linux, Windows, and Mac
1–10 of 28 posts
Re: Inception: DMA Attack Against Linux, Windows, and Mac
#2This 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.
Re: Inception: DMA Attack Against Linux, Windows, and Mac
#3This 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…
> 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.
Re: Inception: DMA Attack Against Linux, Windows, and Mac
#4This 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…
> 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…
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.
Re: Inception: DMA Attack Against Linux, Windows, and Mac
#5[deleted]
Re: Inception: DMA Attack Against Linux, Windows, and Mac
#6Since 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.
Re: Inception: DMA Attack Against Linux, Windows, and Mac
#7It'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.
Re: Inception: DMA Attack Against Linux, Windows, and Mac
#8It'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 almo…
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.
Re: Inception: DMA Attack Against Linux, Windows, and Mac
#9It'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 almo…
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.
Re: Inception: DMA Attack Against Linux, Windows, and Mac
#10This 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…
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.