4 ms·
Casually looking, it seems he misses to use SecureZeroMemory? https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/aa366877(v=vs.85) https
by acqq 6y ago
Casually looking, it seems he misses to use SecureZeroMemory?
https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/aa366877(v=vs.85) https://docs.microsoft.com/en-us/previous-versions/windows/d...
Also note:
"Use this function instead of ZeroMemory when you want to ensure that your data will be overwritten promptly, as some C++ compilers can optimize a call to ZeroMemory by removing it entirely."
Managing passwords is tricky.
Edit: answering: "I don't see the post talking about zeroing memory anywhere?": Exactly. But it uses "free".
free(wbuf);
It is freed without being zeroed. Without demonstrating freeing, and without having the "clean up" part it would not matter. With it, and the given context (writing about using APIs to handle passwords), it does matter, and you should care too. Even more so if you a) aren't aware of the possibility of the compiler optimizations b) haven't even thought about the possible "leaking" issues.
- saagarjha 6y agoI don't see the post talking about zeroing memory anywhere?
- cryptonector 6y agoWell, the blog is about reading passwords. What you do with them is another story.
- yrro 6y agoIt's probably also a good idea to call VirtualLock so that the passwotrd is guaranteed to never be written to virtual memory.
- acqq 6y agoRight, at least, avoiding C allocation and deallocation functions can surely give one more control over the used memory segment. And I am not aware of any discussion of the positive or negative aspects of CryptMemAlloc and CryptMemFree.
- yrro 6y agoDoes the memory managed by these functions have any special properties? The docs don't mention any, other than that these functions are used by Crypt* functions that return buffers (i.e., client sshould free returned buffers with CryptMemFree).
- acqq 6y ago> Does the memory managed by these functions have any special properties? That's what I'd like to read too. It's surely possible to figure that out. Obviously, nothing special is promised by the description of the functions. I know that some people, long ago, even wrote their own kernel drivers to make sure some part of the memory won't end in the virtual memory on the disk. They didn't think VirtualLock gives that guarantee.