Looking at libgcrypt, specifically secmem.c it seems that it does not account for windows-specific memory handling (e.g. VirtualLock) and in fact there is a very troubling comment:

#elif defined (HAVE_DOSISH_SYSTEM) || defined (__CYGWIN__)
    /* It does not make sense to print such a warning, given the fact that
     * this whole Windows !@#$% and their user base are inherently insecure. */

Does this indeed mean that on windows, libgcrypt is not properly hardened against pagedumping etc. ?


VirtualLock is not a security mechanism. It's a performance one.

There's no guarantee the VirtualLocked pages won't be swapped out. Even if they aren't, they'd still get dumped on "hibernation".

The equivalent for VirtualLock in POSIX is mlock, which is implemented by Cygwin(*) and will be used by libgcrypt.

Beyond memory locking, security-hardening encompasses a whole bunch of things to consider.

We assume libgcrypt is written with security as a priority, which includes many best practices to avoid stack overflows, buffer overflows, major flaws in the PRNG, etc.

This includes doing a best-effort attempt at avoiding sensitive data from being left around easily accessible. Sensitive data should be kept in memory for as little time is possible, and during this short time protected as best as possible.

libgcrypt uses mlock as part of this effort, and it will use it on any target platform that has it.

If it's not available, it will print a warning and move on (best-effort). Except in platforms where it doesn't print a warning for various reasons.

The reasons for not printing the warning in windows (that horrible comment) are probably a leftover from older times, when cygwin didn't have an mlock implementation, and Windows' VirtualLock was a nop in all the non-nt versions. Notice that that elsif is only reached if HAVE_MLOCK is false. Check your config.h file after running ./configure to verify yourself that it's set to true under Cygwin.

To summarize: to the best of libgcrypt's developers' knowledge, libgcrypt is properly hardened on all target platforms. If you have reasons to believe otherwise, you should probably file a bug to let them know.

*: Cygwin seems to actually bypass VirtualLock and use NtLockVirtualMemory directly.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.