4 ms·
This seems like a good idea, I'm curious what OpenSSL or other crypto libraries do to keep secrets from being paged out to disk by the virtual memory machine? T
by macrael 15y ago
This seems like a good idea, I'm curious what OpenSSL or other crypto libraries do to keep secrets from being paged out to disk by the virtual memory machine? That seems like a legitimate attack vector.
- bri3d 15y agoOn most platforms, mlock(2) and mlockall "lock" data in memory, theoretically preventing it from being paged to disk. OpenSSL provides hooks for adding a custom allocator which uses mlock, and some of its interfaces allow for the app to allocate its own key space and pass pointers (hence theoretically allowing the app itself to use mlock or whatever platform-specific method of allocating "safe" memory is desired). However, this attack vector is often overlooked and is very commonly exploitable - FileVault and the Login Window on OSX were vulnerable to this brand of attack last I checked. The easiest workaround is to use encrypted swap (and the linked project would be a perfect way to encrypt swap in a way that's not vulnerable to a cold boot attack).
- tptacek 15y agoIt is, but keep in mind that on general-purpose computers running AES, if you can extract secrets from virtual memory, you are already in a position to wiretap the AES process directly.
- bri3d 15y agoA cold-boot attack as detailed in [0] makes it vastly easier to extract secrets from physical memory than to wiretap the AES process, especially if you're not in possession of a privileged user account or a route into kernel space. [0]: http://citpsite.s3-website-us-east-1.amazonaws.com/oldsite-htdocs/pub/coldboot.pdf http://citpsite.s3-website-us-east-1.amazonaws.com/oldsite-h...
- tptacek 15y agoI don't know how to respond to the argument that it's "vastly easier" to chill a bank of RAM with inverted compressed air cans or liquid nitrogen and then extract its entire contents than it is to just use a debugger to watch a program run. I guess "No, I don't agree." suffices.
- bri3d 15y agoWhen you don't have the privilege level to connect a debugger to the process or the secrets are in kernel space, it's probably easier to just reboot with a cold-boot kit attached via USB than to attempt some form of escalation exploit. Inverted air cans or liquid nitrogen are entirely unnecessary in most uses of a cold-boot attack - they're only a requirement if the machine has some form of boot protection and it's desired to transfer the memory modules for some sort of offline forensic analysis. As an additional plus, the tools which the authors of the linked paper have written for identifying key data in memory dumps are simpler to use than tracing the execution flow of even a simple application using a debugger. I'd probably use their approach even with full debug access, as obfuscating control flow around functions handling key data seems to be a more common practice than keeping said data obfuscated in memory.
- macrael 15y agoHow is that possible? Virtual memory is written out to the hard disk, so presumably, anyone with physical access to the drive could read off anything that might be stored there. You wouldn't need admin rights to the box the way you would to force aes to run in gdb, right?
- tptacek 15y agoMy point is just, local attacker, "the call is coming inside the house!". You have big problems at this point.
- haberman 15y agoGPG uses mlock() to prevent swapping, and warns if it cannot do this: http://www.gnupg.org/faq/GnuPG-FAQ.html#why-do-i-get-gpg_warning_using_insecure_memory http://www.gnupg.org/faq/GnuPG-FAQ.html#why-do-i-get-gpg_war...