gpg2: Cảnh báo: sử dụng bộ nhớ không an toàn!


11

Kể từ hôm nay, bất cứ khi nào tôi sử dụng gpg2(được cài đặt qua Homebrew) trên máy Mac của mình (10.12.1), bây giờ tôi thấy cảnh báo sau:

Warning: using insecure memory!

Để biết giá trị của nó, tôi thấy hành vi tương tự trên hai máy khác nhau: Mac mini (cuối năm 2012) và MacBook Pro (cuối năm 2012), cả hai đều chạy 10.12.1.

Như Câu hỏi thường gặp của GnuPG nói:

GnuPG cố gắng khóa bộ nhớ để không có quá trình nào khác có thể nhìn thấy và do đó bộ nhớ sẽ không được ghi để trao đổi. Nếu vì một lý do nào đó, nó không thể làm điều này (ví dụ, một số nền tảng nhất định không hỗ trợ loại khóa bộ nhớ này), GnuPG sẽ cảnh báo bạn rằng nó sử dụng bộ nhớ không an toàn.

Mặc dù sử dụng bộ nhớ an toàn hầu như luôn luôn tốt hơn, nhưng không nhất thiết là sử dụng bộ nhớ không an toàn. Nếu bạn sở hữu máy và bạn tự tin rằng nó không chứa phần mềm độc hại, thì cảnh báo này có thể bị bỏ qua.

Điều gây trở ngại cho tôi là nó gpg2đã không thay đổi kể từ ngày 12 tháng 9 năm 2016 . Kể từ đó, tôi đã cài đặt phiên bản 2.0.30 ít hơn nhưng tôi chỉ bắt đầu thấy cảnh báo này về bộ nhớ không an toàn ngày hôm nay. Mặc dù gpg2công thức đã không thay đổi kể từ ngày 12 tháng 9 năm 2016, nhưng một điều tôi có thể nói chắc chắn rằng tôi đã làm trên cả hai máy trước khi bắt đầu thấy cảnh báo này là a brew update && brew upgrade. Nhưng tôi thậm chí không chắc làm thế nào điều đó có thể ảnh hưởng đến điều này; đưa ra những gì Câu hỏi thường gặp của GnuPG nói, có vẻ như điều này có liên quan nhiều hơn đến hệ điều hành và khóa bộ nhớ.

... Và điều kỳ lạ hơn nữa là tôi cũng đã gpg1cài đặt từ Homebrew (phiên bản 1.4.21), không cảnh báo về bộ nhớ không an toàn khi tôi sử dụng:

$ 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

Cả hai nhị phân thuộc về cùng một chủ sở hữu và nhóm và có cùng quyền:

-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

Tôi vừa thử cài đặt lại gpg2với Homebrew: cả bằng cách sử dụng nhị phân được biên dịch sẵn và bằng cách xây dựng nguồn biểu mẫu, nhưng điều này không thay đổi bất cứ điều gì. Tôi vẫn nhận được cảnh báo về việc sử dụng bộ nhớ không an toàn.

Hơn nữa, ngay cả việc tạo nhị phân gpg2 cũng có bit gốc setuid được lật (như được đề xuất, ví dụ , ở đây ) không làm cho thông báo biến mất; nó vẫn cảnh báo về việc sử dụng bộ nhớ không an toàn.

Có ai biết những gì có thể đã thay đổi như vậy mà tôi sẽ đột nhiên bắt đầu thấy cảnh báo này ngày hôm nay? Và tại sao tôi lại nhìn thấy nó khi sử dụng gpg2nhị phân mà không phải là gpg1nhị phân?

Thông tin khác có thể có liên quan:

$ 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

Cập nhật

Tôi nghĩ lý do điều này xảy ra là vì phiên bản mới của libgcrypt. Tôi vẫn không biết tại sao nó lại xảy ra, nhưng tôi khá chắc chắn rằng đây ít nhất là nguyên nhân cốt lõi của vấn đề. Công thức libgcryptđã được chỉ cập nhật hiện nay cho 1.7.4 vết sưng; điều này sẽ giải thích tại sao tôi thấy điều này trên hai máy tính khác nhau sau một brew update && brew upgrade. Nó cũng sẽ giải thích lý do tại sao nó không xảy ra gpg1, bởi vì gpg1không dựa vào libgcryptthư viện mật mã bên ngoài , thay vào đó sử dụng thư viện mã hóa tích hợp của riêng nó.

Hơn nữa, tôi cũng đã gpg2cài đặt từ MacGPG Suite, không thể hiện vấn đề này và được liên kết với một phiên bản khác của 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.

Vì vậy, tôi đoán rằng đây có lẽ là một báo cáo lỗi cho những người duy trì libgcrypt. Tôi sẽ đăng lên danh sách gửi thư của họ, nhưng tôi sẽ để nó ở đây trong thời gian này trong trường hợp bất kỳ ai khác gặp phải vấn đề tương tự và / hoặc trong trường hợp bất cứ ai khác biết tại sao chính xác điều này đang xảy ra. Nếu tôi nhận được xác nhận sau khi gửi từ vào danh sách gửi thư của họ rằng đây là một lỗi, tôi sẽ bỏ phiếu để đóng câu hỏi này.


Tôi thành thật không chắc chắn nếu câu hỏi này là nhất thích hợp ở đây, trên Apple.SE, hoặc nếu nó thích hợp hơn cho Unix.SE . Tôi đã hỏi ở đây trước vì Câu hỏi thường gặp về GnuPG cho thấy nó có thể là một cái gì đó về việc khóa hệ điều hành và bộ nhớ, nhưng xin vui lòng đề xuất di chuyển nếu bạn nghĩ khác.
Adam Văn

techrepublic.com/blog/it-security/the-insecure-memory-faq dường như đề xuất nguyên nhân có thể là do môi trường của bạn bị thiếu RAM và do đó cần ghi dữ liệu để trao đổi dung lượng.
sIDIAbarker

@sIDIAbarker Đó cũng là suy nghĩ ban đầu của tôi, nhưng (i) sẽ không giải thích được sự khác biệt giữa hành vi với gpg1gpg2, và (ii) Tôi đã theo dõi bộ nhớ trên máy tính của mình khi kiểm tra điều này và có rất nhiều bộ nhớ không sử dụng khi tôi thấy tin nhắn cảnh báo. Tôi nghĩ rằng tôi đã khoanh vùng gốc rễ của vấn đề, nhưng tôi vẫn không chắc tại sao nó lại xảy ra. Sẽ cập nhật câu hỏi trong một giây.
Adam Văn

@sIDIAbarker Cập nhật!
Adam Văn

Câu trả lời:


9

Sự khác biệt giữa gpg1gpg2tôi đã nhận thấy xuất phát từ việc gpg2sử dụng thư viện mật mã bên ngoài libgcrypt, trong khi gpg1sử dụng thư viện mã hóa tích hợp.

Và đặc biệt, Homebrew đã cập nhật lên phiên bản 1.7.4 libgcryptvào ngày 10 tháng 12 , trong đó đưa ra một hồi quy trong libgcryptmã, dẫn đến cảnh báo bộ nhớ không an toàn.

Ban đầu có một chút thảo luận về điều này trong yêu cầu kéo đã đưa công thức libgcrypt1.7.4 vào Homebrew , cho thấy rằng nó có thể là do thiết kế:

Tuy nhiên, hóa ra đây thực sự là một lỗi. Báo cáo lỗi cụ thể đã được nộp tại đây:

Lỗi này đã được sửa trong cam kết này và bản sửa lỗi được phát hành vào ngày libgcrypt1.7.5, tại thời điểm viết bài, giờ đây là phiên bản mà Homebrew cài đặt nhờ có Dominyk Tiller . Vì vậy, để khắc phục vấn đề này, bạn chỉ cần làm một brew update && brew upgrade.


Vì lợi ích của hậu thế, đây là một số thông tin từ phiên bản cũ của câu trả lời này trước khi được xác nhận rằng đây là một lỗi trong libgcrypt:

Một điều bạn có thể làm nếu không phải lúc nào bạn cũng thấy cảnh báo về bộ nhớ không an toàn là thêm no-secmem-warningvào ~/.gnupg/gpg.conf. Một phiên bản cũ của Câu hỏi thường gặp về GnuPG chỉ ra:

Việc khóa các trang không bị tráo đổi là không cần thiết nếu hệ thống của bạn sử dụng phân vùng trao đổi được mã hóa. Trong thực tế đó là cách tốt nhất để bảo vệ dữ liệu nhạy cảm khỏi kết thúc trên đĩa. Nếu hệ thống của bạn cho phép phân vùng trao đổi được mã hóa, vui lòng sử dụng tính năng đó. Lưu ý rằng GPG không biết về phân vùng trao đổi được mã hóa và có thể in cảnh báo; do đó bạn nên tắt cảnh báo nếu phân vùng trao đổi của bạn được mã hóa. Bạn cũng có thể muốn tắt cảnh báo này nếu bạn không thể hoặc không muốn cài đặt GnuPG setuid (root). Để tắt cảnh báo, bạn đặt một dòng

no-secmem-warning

vào ~/.gnupg/gpg.conftập tin của bạn .

Theo tôi biết, macOS không sử dụng không gian hoán đổi được mã hóa. Đối với tôi, ví dụ, sysctl vm.swapusagetrả về:

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

Hơn nữa, như đã @sideshowbarkerchỉ ra trong các bình luận , cũng có một bài đăng trong danh sách gửi thư của người dùng gnupg , nói rằng nó tương đối an toàn để bỏ qua cảnh báo này:

[...] Thật <understatement>khó </understatement>để khai thác bộ nhớ không an toàn mà không có quyền root - và nếu kẻ tấn công của bạn có quyền root trên máy của bạn thì dù sao đi nữa.


Trong ánh sáng của github.com/Homebrew/homebrew-core/pull/ , và thực tế là các nhà libgcryptbảo trì dường như đã phá vỡ điều này một cách có chủ ý, có thể đáng để thêm vào đây rằng tin nhắn có thể bị chặn bằng cách thêm dòng no-secmem-warningvào ~/.gnupg/gpg.conftệp. Như lists.gnupg.org/pipermail/gnupg-users/2015-December/054771.html ghi chú, “đó là khá khó khăn để khai thác bộ nhớ không an toàn không dùng root - và nếu kẻ tấn công của bạn có quyền root trên máy tính của bạn sau đó nó khắp nơi trên nào Mùi. Vì vậy, cảnh báo không hữu ích để bắt đầu.
sIDIAbarker
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.