gpg2: Ostrzeżenie: używanie niepewnej pamięci!

11

Na dzień dzisiejszy za każdym razem, gdy korzystam gpg2(instalowany przez Homebrew) na komputerze Mac (10.12.1), teraz widzę następujące ostrzeżenie:

Warning: using insecure memory!

Co do tego warte, widzę to samo zachowanie na dwóch różnych komputerach: Mac mini (pod koniec 2012 r.) I MacBook Pro (pod koniec 2012 r.), Oba z uruchomionym 10.12.1.

Jak mówi GnuPG FAQ :

GnuPG próbuje zablokować pamięć, aby żaden inny proces jej nie widział i aby pamięć nie została zapisana do zamiany. Jeśli z jakiegoś powodu nie jest w stanie tego zrobić (na przykład niektóre platformy nie obsługują tego rodzaju blokowania pamięci), GnuPG ostrzeże cię, że używa niepewnej pamięci.

Chociaż prawie zawsze lepiej jest korzystać z bezpiecznej pamięci, niekoniecznie jest złą rzeczą korzystanie z niepewnej pamięci. Jeśli posiadasz maszynę i masz pewność, że nie zawiera ona złośliwego oprogramowania, to ostrzeżenie to prawdopodobnie można zignorować.

Zaskakuje mnie to, że gpg2nie zmieniło się od 12 września 2016 r . Od tego czasu mam mniej więcej wersję 2.0.30, ale dzisiaj zaczęłam widzieć to ostrzeżenie o niebezpiecznej pamięci. Chociaż gpg2formuła nie zmieniła się od 12 września 2016 r., Jedno mogę powiedzieć na pewno, że zrobiłem to na obu komputerach przed pojawieniem się tego ostrzeżenia brew update && brew upgrade. Ale nie jestem nawet pewien, jak to może na to wpłynąć; Biorąc pod uwagę to, co mówi GnuPG FAQ, wygląda na to, że ma to coś więcej wspólnego z systemem operacyjnym i blokowaniem pamięci.

... Co jeszcze dziwniejsze, że gpg1zainstalowałem również z Homebrew (wersja 1.4.21), która nie ostrzega przed niebezpieczną pamięcią podczas jej używania:

$ 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

Oba pliki binarne należą do tego samego właściciela i grupy i mają takie same uprawnienia:

-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

Właśnie próbowałem ponownej instalacji gpg2z Homebrew: zarówno przy użyciu prekompilowanego pliku binarnego, jak i przez zbudowanie źródła formularza, ale to nic nie zmienia. Nadal pojawia się ostrzeżenie o używaniu niepewnej pamięci.

Co więcej, nawet czyniąc gpg2 binarne mają bitu setuid korzeniowy odbitym (jak sugerowano, np , tutaj ) nie powoduje komunikat zniknie; wciąż ostrzega przed użyciem niepewnej pamięci.

Czy ktoś wie, co mogło się zmienić tak, że nagle zacznę widzieć dziś to ostrzeżenie? I dlaczego miałbym to widzieć, gdy używam gpg2pliku binarnego, ale nie gpg1binarnego?

Inne potencjalnie istotne informacje:

$ 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

Aktualizacja

Myślę, że dzieje się tak z powodu nowej wersji libgcrypt. Nadal nie wiem, dlaczego tak się dzieje, ale jestem prawie pewien, że jest to przynajmniej podstawowa przyczyna problemu. Formuła dla libgcryptzostała właśnie zaktualizowana dzisiaj dla guza 1.7.4; to by wyjaśniało, dlaczego widzę to na dwóch różnych komputerach po brew update && brew upgrade. Wyjaśniałoby to również, dlaczego tak się nie dzieje gpg1, ponieważ gpg1nie polegał na zewnętrznej libgcryptbibliotece kryptograficznej, zamiast tego używał własnej zintegrowanej biblioteki kryptograficznej.

Ponadto gpg2zainstalowałem również pakiet MacGPG, który nie wykazuje tego problemu i jest powiązany z inną wersją 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.

Zgaduję więc, że jest to prawdopodobnie raport o błędzie dla opiekunów libgcrypt. Będę publikować na ich liście mailingowej, ale na razie zostawię to tutaj, na wypadek, gdyby ktoś napotkał ten sam problem i / lub na wypadek, gdyby ktokolwiek wiedział, dlaczego tak się dzieje. Jeśli po wysłaniu wiadomości na ich listę mailową otrzymam potwierdzenie, że jest to błąd, zagłosuję za zamknięciem tego pytania.

Adam Liter
źródło
Jestem szczerze nie wiem, czy to pytanie jest najwłaściwszym tutaj, na Apple.SE, lub jeśli jest to bardziej odpowiednie dla Unix.SE . Zapytałem tutaj najpierw, ponieważ FAQ GnuPG sugeruje, że może to być coś na temat blokowania systemu operacyjnego i pamięci, ale proszę sugerować migrację, jeśli uważasz inaczej.
Adam Liter
techrepublic.com/blog/it-security/the-insecure-memory-faq wydaje się sugerować, że przyczyną może być niski poziom pamięci RAM i konieczność zapisywania danych w celu zamiany przestrzeni.
sideshowbarker
@sideshowbarker To była moja pierwsza myśl, jak dobrze, ale (i), że nie byłoby wyjaśnić różnice między zachowaniem się gpg1i gpg2, oraz (ii) Mam monitoruje pamięć na moim komputerze podczas testowania tego, a jest mnóstwo niewykorzystanej pamięci kiedy widzę komunikat ostrzegawczy. Myślę, że zlokalizowałem źródło problemu, ale nadal nie jestem pewien, dlaczego tak się dzieje. Zaktualizuje pytanie za sekundę.
Adam Liter
@sideshowbarker Zaktualizowano!
Adam Liter

Odpowiedzi:

9

Różnica pomiędzy gpg1i gpg2że byłem zauważając wynika z faktu, że gpg2korzysta z zewnętrznego biblioteki kryptograficznej, libgcrypt, podczas gdy gpg1korzysta ze zintegrowanej biblioteki kryptograficzne.

W szczególności Homebrew zaktualizowano do wersji 1.7.4 libgcrypt10 grudnia , która wprowadziła regresję w libgcryptkodzie, prowadząc do niebezpiecznego ostrzeżenia o pamięci.

Na początku była trochę dyskusji na ten temat na żądanie ściągnięcia, które wprowadziło formułę libgcrypt1.7.4 do Homebrew , sugerując, że może to być projekt:

Niemniej jednak okazuje się, że był to rzeczywiście błąd. Konkretny raport o błędzie został złożony tutaj:

Błąd został naprawiony w tym zatwierdzeniu , a poprawka została wydana w wersji libgcrypt1.7.5, która w chwili pisania tego tekstu jest teraz wersją instalowaną przez Homebrew dzięki Dominyk Tiller . Tak więc, aby rozwiązać ten problem, możesz po prostu zrobić brew update && brew upgrade.


Dla potomności, oto kilka informacji ze starej wersji tej odpowiedzi, zanim potwierdzono, że był to błąd w libgcrypt:

Jedną z rzeczy, które możesz zrobić, jeśli wolisz nie zawsze widzieć ostrzeżenie o niepewnej pamięci, jest dodanie no-secmem-warningdo niej ~/.gnupg/gpg.conf. Stara wersja GnuPG FAQ zaznacza:

Blokowanie stron przed zamianą nie jest konieczne, jeśli system korzysta z zaszyfrowanej partycji wymiany. W rzeczywistości jest to najlepszy sposób ochrony poufnych danych przed dostaniem się na dysk. Jeśli twój system pozwala na szyfrowane partycje wymiany, skorzystaj z tej funkcji. Pamiętaj, że GPG nie wie o zaszyfrowanych partycjach wymiany i może wydrukować ostrzeżenie; dlatego należy wyłączyć ostrzeżenie, jeśli partycja wymiany jest zaszyfrowana. Możesz także wyłączyć to ostrzeżenie, jeśli nie możesz lub nie chcesz instalować GnuPG setuid (root). Aby wyłączyć ostrzeżenie, wstaw linię

no-secmem-warning

do twojego ~/.gnupg/gpg.confpliku.

O ile mi wiadomo, macOS używa zaszyfrowanej przestrzeni wymiany. Dla mnie na przykład sysctl vm.swapusagezwraca:

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

Ponadto, jak @sideshowbarkerwskazano w komentarzach , na liście mailingowej gnupg-users znajduje się również post , który mówi, że względnie bezpiecznie można zignorować to ostrzeżenie:

[...] <understatement>bardzo trudno </understatement>jest wykorzystać niepewną pamięć bez uprawnień roota - a jeśli twój atakujący ma uprawnienia roota na twoim komputerze, to i tak jest po wszystkim.

Adam Liter
źródło
W świetle github.com/Homebrew/homebrew-core/pull/… oraz faktu, że libgcryptopiekunowie najwyraźniej złamali to celowo, warto dodać tutaj, że wiadomość można ukryć, dodając wiersz no-secmem-warningdo ~/.gnupg/gpg.confpliku. Jak zauważa lists.gnupg.org/pipermail/gnupg-users/2015-December/054771.html: „bardzo trudno jest wykorzystać niepewną pamięć bez uprawnień roota - a jeśli twój atakujący ma uprawnienia roota na twoim komputerze, to i tak wszystko jest skończone. ”. Dlatego ostrzeżenie nie jest bardzo przydatne na początek.
sideshowbarker