11

As of today, whenever I use gpg2 (installed via Homebrew) on my Mac (10.12.1), I now see the following warning:

Warning: using insecure memory!

For what it's worth, I'm seeing this same behavior on two different machines: a Mac mini (late 2012) and a MacBook Pro (late 2012), both running 10.12.1.

As the GnuPG FAQ says:

GnuPG tries to lock memory so that no other process can see it and so that the memory will not be written to swap. If for some reason it’s not able to do this (for instance, certain platforms don’t support this kind of memory locking), GnuPG will warn you that it’s using insecure memory.

While it’s almost always better to use secure memory, it’s not necessarily a bad thing to use insecure memory. If you own the machine and you’re confident it’s not harboring malware, then this warning can probably be ignored.

The thing that baffles me is that gpg2 has not changed since September 12, 2016. I've had version 2.0.30 installed more or less since then, but I've only started seeing this warning about insecure memory today. Even though the gpg2 formula hasn't changed since September 12, 2016, the one thing I can say for sure that I did on both machines prior to the onset of seeing this warning is a brew update && brew upgrade. But I'm not even sure how that could affect this; given what the GnuPG FAQ says, it seems like this has something more to do with the OS and memory locking.

... And what is even more odd is that I also have gpg1 installed from Homebrew (version 1.4.21), which does not warn about insecure memory when I use it:

$ gpg1 --require-secmem
gpg: Go ahead and type your message ...
^C
gpg: Interrupt caught ... exiting

$ gpg2 --require-secmem
Warning: using insecure memory!
gpg: will not run with insecure memory due to --require-secmem

Both binaries belong to the same owner and group and have the same permissions:

-r-xr-xr-x  1 adamliter  admin  681932 Dec 10 18:06 /usr/local/Cellar/gnupg2/2.0.30_2/bin/gpg2
-r-xr-xr-x  1 adamliter  admin  929352 Aug 17 09:21 /usr/local/Cellar/gnupg/1.4.21/bin/gpg1

I just tried reinstalling gpg2 with Homebrew: both by using the precompiled binary and by building form source, but this doesn't change anything. I still get the warning about using insecure memory.

Moreover, even making the gpg2 binary have the setuid root bit flipped (as suggested, e.g., here) does not cause the message to disappear; it still warns about using insecure memory.

Does anyone know what could have changed such that I would suddenly start seeing this warning today? And why would I be seeing it when using the gpg2 binary but not the gpg1 binary?

Other possibly relevant information:

$ which gpg1
/usr/local/bin/gpg1
$ ls -al /usr/local/bin/gpg1
lrwxr-xr-x  1 adamliter  admin  31 Aug 17 17:42 /usr/local/bin/gpg1 -> ../Cellar/gnupg/1.4.21/bin/gpg1
$ which gpg2
/usr/local/bin/gpg2
$ ls -al /usr/local/bin/gpg2
lrwxr-xr-x  1 adamliter  admin  34 Dec 10 18:06 /usr/local/bin/gpg2 -> ../Cellar/gnupg2/2.0.30_2/bin/gpg2

Update

I think the reason this is happening is because of the new version of libgcrypt. I still don't know why it's happening, but I'm pretty sure that this is at least the root cause of the issue. The formula for libgcrypt was just updated today for the 1.7.4 bump; this would explain why I'm seeing this on two different computers after a brew update && brew upgrade. It would also explain why it's not happening with gpg1, because gpg1 did not rely on the external libgcrypt cryptographic library, instead using its own integrated cryptographic library.

Moreover, I also have gpg2 installed from MacGPG Suite, which is not exhibiting this problem and is linked against a different version of libgcrypt:

$ /usr/local/MacGPG2/bin/gpg2 --version
gpg (GnuPG/MacGPG2) 2.0.30
libgcrypt 1.6.6
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ gpg2 --version
gpg (GnuPG) 2.0.30
libgcrypt 1.7.4
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Thus I'm guessing that this is probably a bug report for the maintainers of libgcrypt. I will post to their mailing list, but I will leave this here for the time being in case anyone else comes across the same issue and/or in case anyone else knows why exactly this is happening. If I get confirmation after sending word to their mailing list that this is a bug, I'll vote to close this question.

  • I'm honestly not sure if this question is most appropriate here, on Apple.SE, or if it's more appropriate for Unix.SE. I asked here first because the GnuPG FAQ suggests it might be something about the OS and memory locking, but please feel free to suggest a migration if you think otherwise. – Adam Liter Dec 10 '16 at 23:59
  • techrepublic.com/blog/it-security/the-insecure-memory-faq seems to suggest the cause might be due to your environment having gotten low on RAM and so needing to write data to swap space. – sideshowbarker Dec 11 '16 at 0:35
  • @sideshowbarker That was my initial thought as well, but (i) that wouldn't explain the differences between the behavior with gpg1 and gpg2, and (ii) I've been monitoring memory on my computer when testing this, and there's plenty of unused memory when I see the warning message. I think I've localized the root of the issue, but I'm still not sure why it is happening. Will update the question in a second. – Adam Liter Dec 11 '16 at 0:41
  • @sideshowbarker Updated! – Adam Liter Dec 11 '16 at 0:56
  • 1
9

The difference between gpg1 and gpg2 that I was noticing arises from the fact that gpg2 uses an external cryptographic library, libgcrypt, whereas gpg1 uses an integrated cryptographic library.

And specifically, Homebrew updated to version 1.7.4 of libgcrypt on December 10, which introduced a regression in the libgcrypt code, leading to the insecure memory warning.

There was initially a bit of discussion about this on the pull request that introduced the formula for libgcrypt 1.7.4 into Homebrew, suggesting that it might be by design:

Nonetheless, it turns out that this was indeed a bug. The specific bug report was filed here:

The bug was fixed in this commit, and the fix was released in libgcrypt 1.7.5, which, at the time of writing, is now the version that Homebrew installs thanks to Dominyk Tiller. Thus, to fix this problem, you can just do a brew update && brew upgrade.


For posterity's sake, here is some information from an old version of this answer before it was confirmed that this was a bug in libgcrypt:

One thing you can do if you'd rather not always see the warning about insecure memory is to add no-secmem-warning to ~/.gnupg/gpg.conf. An old version of the GnuPG FAQ points out:

Locking pages against being swapped out is not necessary if your system uses an encrypted swap partition. In fact that is the best way to protect sensitive data from ending up on a disk. If your system allows for encrypted swap partitions, please make use of that feature. Note that GPG does not know about encrypted swap partitions and might print the warning; thus you should disabled the warning if your swap partition is encrypted. You may also want to disable this warning if you can't or don't want to install GnuPG setuid(root). To disable the warning you put a line

no-secmem-warning

into your ~/.gnupg/gpg.conf file.

As far as I know, macOS does use encrypted swap space. For me, for example, sysctl vm.swapusage returns:

vm.swapusage: total = 1024.00M  used = 234.75M  free = 789.25M  (encrypted)

Furthermore, as @sideshowbarker points out in the comments, there is also a post to the gnupg-users mailing list, which says it's relatively safe to ignore this warning:

[...] it's <understatement> pretty hard </understatement> to exploit insecure memory without root privileges -- and if your attacker has root privileges on your machine then it's all over anyway.

  • In light of github.com/Homebrew/homebrew-core/pull/… and the fact that the libgcrypt maintainers seem to have broken this intentionally, it might be worth adding here that the message can be suppressed by adding the line no-secmem-warning to the ~/.gnupg/gpg.conf file. As lists.gnupg.org/pipermail/gnupg-users/2015-December/054771.html notes, “it's pretty hard to exploit insecure memory without root privileges -- and if your attacker has root privileges on your machine then it's all over anyway”. So the warning isn’t very useful to begin with. – sideshowbarker Dec 14 '16 at 8:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .