On 3/1/18, Prashant Chaudhari <[email protected]> wrote: > I would like to add attached patch, which zero out the user defined data. I > am particularly targeting to reset the password/authentication secrets.
I gave the proposed fix a quick look and think that it does not actually meet the stated goal of securely overwriting sensitive data. The correct fix will take more work, and I don't like this change as-is because it gives the reader a false sense of security. The first problem is that any decent optimizing compiler will see the memset() followed by free() as a dead store and will optimize it away. <http://www.daemonology.net/blog/2014-09-04-how-to-zero-a-buffer.html> is a pretty good description of how and why that works. The bad news is that there is no portable function that does the job. memset_s() is available on some (many? most?) UNICes, but it's fairly recent (C11); on Windows you would use SecureZeroMemory(). For more on the topic, read <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1381.pdf> and <https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-yang.pdf>. The second, harder, problem is that you have no guarantee that the sensitive data is only stored in that location. On a system has swap enabled without encryption, it is very possible for the sensitive data to be swapped to disk, which copy will be unaffected by any secure memory overwrite function you can find. To be more safe, we would need to tell the OS to allocate some memory that it will never swap, which task is also non-portable. And even if we solve those two problems, I won't say for sure that we have securely erased the sensitive data. Just because I can't think of another route of attack doesn't mean that none exists. Harold ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
