gpg2: Warnung: Verwendung von unsicherem Speicher!

Ab heute wird bei gpg2jeder Verwendung (über Homebrew installiert) auf meinem Mac (10.12.1) die folgende Warnung angezeigt:

Warning: using insecure memory!

Ich sehe dasselbe Verhalten auf zwei verschiedenen Rechnern: einem Mac mini (Ende 2012) und einem MacBook Pro (Ende 2012), die beide 10.12.1 ausführen.

Wie die GnuPG FAQ sagt:

GnuPG versucht, den Speicher zu sperren, damit kein anderer Prozess ihn sehen kann und der Speicher nicht zum Auslagern geschrieben wird. Wenn dies aus irgendeinem Grund nicht möglich ist (zum Beispiel unterstützen bestimmte Plattformen diese Art der Speichersperrung nicht), warnt GnuPG Sie, dass unsicherer Speicher verwendet wird.

Während es fast immer besser ist, sicheren Speicher zu verwenden, ist es nicht unbedingt eine schlechte Sache, unsicheren Speicher zu verwenden. Wenn Ihnen der Computer gehört und Sie sicher sind, dass er keine Malware enthält, kann diese Warnung möglicherweise ignoriert werden.

Was mich verwundert, ist, dass gpg2sich seit dem 12. September 2016 nichts geändert hat . Ich habe seitdem mehr oder weniger Version 2.0.30 installiert, aber diese Warnung über unsicheren Speicher wird heute erst angezeigt. Auch wenn sich die gpg2Formel seit dem 12. September 2016 nicht geändert hat, kann ich mit Sicherheit sagen, dass ich vor dem Einsetzen dieser Warnung auf beiden Computern Folgendes getan habe: a brew update && brew upgrade. Aber ich bin mir nicht mal sicher, wie sich das auswirken könnte. Wenn man bedenkt, was in den GnuPG-FAQ steht, scheint dies mehr mit dem Betriebssystem und der Speichersperrung zu tun zu haben.

... Und was noch seltsamer ist, ist, dass ich gpg1Homebrew (Version 1.4.21) installiert habe, das nicht vor unsicherem Speicher warnt, wenn ich es verwende:

$ 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

Beide Binärdateien gehören demselben Besitzer und derselben Gruppe und haben dieselben Berechtigungen:

-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

Ich habe gerade versucht, gpg2mit Homebrew neu zu installieren : sowohl mit Hilfe der vorkompilierten Binärdatei als auch durch Erstellen der Formularquelle, aber das ändert nichts. Ich bekomme immer noch die Warnung über die Verwendung von unsicherem Speicher.

Darüber hinaus, auch die gpg2 binär zu machen hat die setuid root Bit umgedreht (wie vorgeschlagen, zum Beispiel , hier ) die Nachricht nicht verschwinden lassen; Es wird weiterhin vor unsicherem Speicher gewarnt.

Weiß jemand, was sich hätte ändern können, so dass ich diese Warnung heute plötzlich sehe? Und warum sollte ich es sehen, wenn ich die gpg2Binärdatei verwende, aber nicht die gpg1Binärdatei?

Andere möglicherweise relevante Informationen:

$ 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

Aktualisieren

Ich denke, der Grund dafür liegt in der neuen Version von libgcrypt. Ich weiß immer noch nicht, warum es passiert, aber ich bin mir ziemlich sicher, dass dies zumindest die Ursache des Problems ist. Die Formel für libgcryptwurde heute für die 1.7.4-Erhebung aktualisiert . dies würde erklären, warum ich dies nach einem auf zwei verschiedenen Computern sehe brew update && brew upgrade. Es würde auch erklären, warum dies nicht der Fall ist gpg1, da gpg1keine externe libgcryptkryptografische Bibliothek verwendet wurde, sondern eine eigene integrierte kryptografische Bibliothek verwendet wurde.

Darüber hinaus habe ich auch die gpg2MacGPG Suite installiert, die dieses Problem nicht aufweist und mit einer anderen Version von verknüpft ist 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.

^{Daher schätze ich, dass dies wahrscheinlich ein Fehlerbericht für die Betreuer von ist libgcrypt. Ich werde auf ihre Mailing-Liste schreiben, aber ich werde dies vorerst hier belassen, falls jemand anderes auf dasselbe Problem stößt und / oder falls jemand anderes weiß, warum genau dies geschieht. Wenn ich nach dem Senden einer Nachricht an die Mailingliste eine Bestätigung erhalte, dass dies ein Fehler ist, stimme ich ab, um diese Frage zu schließen.}

Der Unterschied zwischen gpg1und gpg2, den ich bemerkte, ergibt sich aus der Tatsache, dass gpg2eine externe kryptografische Bibliothek verwendet wird libgcrypt, während gpg1eine integrierte kryptografische Bibliothek verwendet wird.

Insbesonderelibgcrypt wurde Homebrew am 10. Dezember auf Version 1.7.4 aktualisiert , wodurch eine Regression im libgcryptCode eingeführt wurde, die zu einer Warnung bezüglich des unsicheren Speichers führte.

Anfänglich wurde dies in Bezug auf die Pull-Anforderunglibgcrypt diskutiert , mit der die Formel für 1.7.4 in Homebrew eingeführt wurde , was darauf hindeutet, dass dies beabsichtigt sein könnte:

• Dominyk Tiller fand etwas, das darauf hindeutet, dass es sich nicht um einen Bug handelt . und
• @ilovezfshabe auch etwas gefunden , das darauf hindeutet, dass es auch kein Bug ist .

Es stellt sich jedoch heraus, dass dies tatsächlich ein Fehler war. Der spezifische Fehlerbericht wurde hier abgelegt:

• libgcrypt 1.7.4 breaket KWallet5: "Kann keinen sicheren Speicher bekommen" von GCRYCTL_INIT_SECMEM

Der Fehler wurde in diesem Commit behoben , und der Fix wurde in libgcrypt1.7.5 veröffentlicht. Dies ist zum Zeitpunkt des Schreibens die Version, die Homebrew dank Dominyk Tiller installiert . Um dieses Problem zu beheben, können Sie also einfach a brew update && brew upgrade.

Der Nachwelt halber hier einige Informationen aus einer alten Version dieser Antwort, bevor bestätigt wurde, dass dies ein Fehler in war libgcrypt:

Eine Sache , die Sie tun können , wenn Sie lieber nicht immer die Warnung über unsichere Speicher sehen , ist hinzuzufügen , no-secmem-warningzu ~/.gnupg/gpg.conf. Eine alte Version der GnuPG-FAQ weist darauf hin:

Das Sperren von Seiten gegen Auslagerung ist nicht erforderlich, wenn Ihr System eine verschlüsselte Auslagerungspartition verwendet. In der Tat ist dies der beste Weg, um sensible Daten davor zu schützen, auf einer Festplatte zu landen. Wenn Ihr System verschlüsselte Swap-Partitionen zulässt, nutzen Sie diese Funktion. Beachten Sie, dass GPG nichts über verschlüsselte Swap-Partitionen weiß und möglicherweise die Warnung ausgibt. Daher sollten Sie die Warnung deaktivieren, wenn Ihre Swap-Partition verschlüsselt ist. Sie können diese Warnung auch deaktivieren, wenn Sie GnuPG setuid (root) nicht installieren können oder wollen. Um die Warnung zu deaktivieren, setzen Sie eine Linie

no-secmem-warning

in deine ~/.gnupg/gpg.confDatei.

Soweit ich weiß, verwendet macOS verschlüsselten Swap Space. Für mich gibt es zum Beispiel sysctl vm.swapusage:

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

Darüber hinaus gibt es, wie @sideshowbarkerin den Kommentaren erwähnt , auch einen Post auf der Mailingliste von gnupg-users , der besagt, dass es relativ sicher ist, diese Warnung zu ignorieren:

[...] es ist <understatement>ziemlich schwer </understatement>, unsicheren Speicher ohne root-Rechte auszunutzen - und wenn Ihr Angreifer root-Rechte auf Ihrem Rechner hat, ist es sowieso vorbei.