gpg2: Attention: utilisation d'une mémoire non sécurisée!

À partir d'aujourd'hui, chaque fois que j'utilise gpg2(installé via Homebrew) sur mon Mac (10.12.1), je vois maintenant l'avertissement suivant:

Warning: using insecure memory!

Pour ce que ça vaut, je vois ce même comportement sur deux machines différentes: un Mac mini (fin 2012) et un MacBook Pro (fin 2012), tous deux exécutant 10.12.1.

Comme le dit la FAQ GnuPG :

GnuPG essaie de verrouiller la mémoire pour qu'aucun autre processus ne puisse la voir et pour que la mémoire ne soit pas écrite pour permuter. Si pour une raison quelconque, il n'est pas en mesure de le faire (par exemple, certaines plates-formes ne prennent pas en charge ce type de verrouillage de la mémoire), GnuPG vous avertira qu'il utilise une mémoire non sécurisée.

Bien qu'il soit presque toujours préférable d'utiliser une mémoire sécurisée, ce n'est pas nécessairement une mauvaise chose d'utiliser une mémoire non sécurisée. Si vous possédez la machine et que vous êtes sûr qu'elle ne contient pas de logiciels malveillants, cet avertissement peut probablement être ignoré.

Ce qui me déconcerte, c'est que cela gpg2n'a pas changé depuis le 12 septembre 2016 . J'ai installé la version 2.0.30 plus ou moins depuis, mais je n'ai commencé à voir cet avertissement concernant la mémoire non sécurisée qu'aujourd'hui. Même si la gpg2formule n'a pas changé depuis le 12 septembre 2016, la seule chose que je peux dire avec certitude que j'ai fait sur les deux machines avant le début de voir cet avertissement est un brew update && brew upgrade. Mais je ne sais même pas comment cela pourrait affecter cela; étant donné ce que dit la FAQ GnuPG, il semble que cela ait quelque chose à voir avec le système d'exploitation et le verrouillage de la mémoire.

... Et ce qui est encore plus étrange, c'est que j'ai également gpg1installé à partir de Homebrew (version 1.4.21), qui ne prévient pas de la mémoire non sécurisée lorsque je l'utilise:

$ 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

Les deux fichiers binaires appartiennent au même propriétaire et au même groupe et ont les mêmes autorisations:

-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

J'ai juste essayé de réinstaller gpg2avec Homebrew: à la fois en utilisant le binaire précompilé et en créant une source de formulaire, mais cela ne change rien. Je reçois toujours l'avertissement concernant l'utilisation d'une mémoire non sécurisée.

De plus, même en faisant l'gpg2 binaire ont le bit suid root basculée (comme l'a suggéré, par exemple , ici ) ne provoque pas le message à disparaître; il met toujours en garde contre l'utilisation d'une mémoire non sécurisée.

Est-ce que quelqu'un sait ce qui aurait pu changer de telle sorte que je commencerais soudain à voir cet avertissement aujourd'hui? Et pourquoi le verrais-je en utilisant le gpg2binaire mais pas le gpg1binaire?

Autres informations éventuellement pertinentes:

$ 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

Mise à jour

Je pense que la raison pour laquelle cela se produit est à cause de la nouvelle version de libgcrypt. Je ne sais toujours pas pourquoi cela se produit, mais je suis presque sûr que c'est au moins la cause profonde du problème. La formule libgcrypta été juste mis à jour aujourd'hui pour la bosse 1.7.4; cela expliquerait pourquoi je vois cela sur deux ordinateurs différents après a brew update && brew upgrade. Cela expliquerait également pourquoi cela ne se produit pas gpg1, car gpg1ne s'appuyait pas sur la libgcryptbibliothèque cryptographique externe , utilisant plutôt sa propre bibliothèque cryptographique intégrée.

De plus, j'ai également gpg2installé à partir de MacGPG Suite, qui ne présente pas ce problème et est lié à une version différente de 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.

^{Je suppose donc qu'il s'agit probablement d'un rapport de bogue pour les responsables de libgcrypt. Je posterai sur leur liste de diffusion, mais je laisserai ceci ici pour le moment au cas où quelqu'un d'autre rencontrerait le même problème et / ou si quelqu'un d'autre sait exactement pourquoi cela se produit. Si je reçois la confirmation après avoir envoyé un mot à leur liste de diffusion qu'il s'agit d'un bug, je voterai pour fermer cette question.}

La différence entre gpg1et gpg2que je remarquais vient du fait qu'il gpg2utilise une bibliothèque cryptographique externe libgcrypt, alors qu'il gpg1utilise une bibliothèque cryptographique intégrée.

Et spécifiquement, Homebrew a été mis à jour vers la version 1.7.4 du libgcrypt10 décembre , ce qui a introduit une régression dans le libgcryptcode, conduisant à l'avertissement de mémoire non sécurisée.

Il y avait initialement un peu de discussion à ce sujet sur la demande de pull qui a introduit la formule pour libgcrypt1.7.4 dans Homebrew , suggérant que cela pourrait être par conception:

• Dominyk Tiller a trouvé quelque chose pour suggérer qu'il ne s'agissait peut-être pas d'un bug ; et
• @ilovezfsa également trouvé quelque chose pour suggérer que ce n'était peut-être pas un bug non plus .

Néanmoins, il s'avère que c'était effectivement un bug. Le rapport de bogue spécifique a été déposé ici:

• libgcrypt 1.7.4 casse KWallet5: "Impossible d'obtenir la mémoire sécurisée" de GCRYCTL_INIT_SECMEM

Le bug a été corrigé dans ce commit , et le correctif a été publié en libgcrypt1.7.5, qui, au moment de la rédaction, est maintenant la version que Homebrew installe grâce à Dominyk Tiller . Ainsi, pour résoudre ce problème, vous pouvez simplement faire un brew update && brew upgrade.

Pour la postérité, voici quelques informations d'une ancienne version de cette réponse avant qu'il ne soit confirmé qu'il s'agissait d'un bug dans libgcrypt:

Une chose que vous pouvez faire si vous verriez plutôt pas toujours l'avertissement sur la mémoire non sécurisé est d'ajouter no-secmem-warningà ~/.gnupg/gpg.conf. Une ancienne version de la FAQ GnuPG souligne:

Le verrouillage des pages contre la permutation n'est pas nécessaire si votre système utilise une partition de permutation cryptée. En fait, c'est la meilleure façon de protéger les données sensibles de ne pas se retrouver sur un disque. Si votre système autorise les partitions d'échange cryptées, veuillez utiliser cette fonctionnalité. Notez que GPG ne connaît pas les partitions de swap chiffrées et peut afficher l'avertissement; vous devez donc désactiver l'avertissement si votre partition de swap est cryptée. Vous pouvez également désactiver cet avertissement si vous ne pouvez pas ou ne souhaitez pas installer GnuPG setuid (root). Pour désactiver l'avertissement, vous mettez une ligne

no-secmem-warning

dans votre ~/.gnupg/gpg.conffichier.

Pour autant que je sache, macOS utilise un espace d'échange crypté. Pour moi, par exemple, sysctl vm.swapusagerenvoie:

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

En outre, comme le @sideshowbarkersouligne les commentaires , il existe également un message sur la liste de diffusion gnupg-users , qui indique qu'il est relativement sûr d'ignorer cet avertissement:

[...] il est <understatement>assez difficile </understatement>d'exploiter la mémoire non sécurisée sans privilèges root - et si votre attaquant a des privilèges root sur votre machine, alors c'est fini de toute façon.