Gpg.fail

 (gpg.fail)
4 điểm bởi GN⁺ 2025-12-28 | 1 bình luận | Chia sẻ qua WhatsApp
  • Một website công khai nhiều lỗ hổng bảo mật liên quan đến GnuPG, kèm liên kết tới trang mô tả chi tiết cho từng lỗ hổng
  • Trang web liệt kê nhiều trường hợp sự cố khác nhau phát sinh trong quá trình ký PGP, mã hóa và xác minh độ tin cậy
  • Các hạng mục chính bao gồm tấn công bản rõ, duyệt đường dẫn, lỗi tính toán hash, hỏng bộ nhớ, giả mạo chữ ký v.v.
  • Người vận hành cho biết đang gấp rút viết lại website và sẽ sớm công bố slide, PoC và bản vá
  • Đây là một trường hợp cho thấy sự cần thiết phải kiểm chứng nghiêm túc đối với tính toàn vẹn chữ ký và mô hình tin cậy của các công cụ bảo mật mã nguồn mở

Tổng quan về trang web

  • gpg.fail là một website tổng hợp và công khai các lỗ hổng của GnuPG (triển khai OpenPGP)
    • Mỗi mục dẫn tới một liên kết riêng tới trang phân tích kỹ thuật chi tiết
    • Người vận hành cho biết: “Tôi để mã nguồn website ở nhà nên đang viết lại, hãy chờ một phiên bản tốt hơn vào ngày mai”
  • Phần đầu trang có dòng “Slides, pocs and patches soon!” để báo trước việc công bố thêm tài liệu trong thời gian tới

Danh sách các lỗ hổng chính đã công bố

  • Multiple Plaintext Attack on Detached PGP Signatures
    • Chỉ ra khả năng thực hiện tấn công đa bản rõ đối với chữ ký PGP tách rời
  • GnuPG Accepts Path Separators and Path Traversals in Literal Data "Filename" Field
    • GnuPG cho phép ký tự phân tách đường dẫn và path traversal trong trường tên tệp của literal data
  • Cleartext Signature Plaintext Truncated for Hash Calculation
    • Xảy ra vấn đề bản rõ bị cắt cụt khi tính hash
  • Encrypted message malleability checks are incorrectly enforced causing plaintext recovery attacks
    • Việc kiểm tra tính khả biến của bản mã được thực thi không chính xác, dẫn đến tấn công khôi phục bản rõ
  • Memory Corruption in ASCII-Armor Parsing
    • Có khả năng xảy ra hỏng bộ nhớ trong quá trình phân tích ASCII-Armor
  • Trusted comment injection (minisign)
    • Có khả năng chèn trusted comment trong minisign
  • Cleartext Signature Forgery in the NotDashEscaped header implementation in GnuPG
    • Có khả năng giả mạo chữ ký bản rõ trong phần triển khai header NotDashEscaped
  • OpenPGP Cleartext Signature Framework Susceptible to Format Confusion
    • Dễ bị tổn thương trước format confusion trong framework chữ ký bản rõ
  • GnuPG Output Fails To Distinguish Signature Verification Success From Message Content
    • Đầu ra không phân biệt được giữa việc xác minh chữ ký thành công và nội dung thông điệp
  • Cleartext Signature Forgery in GnuPG
    • Có khả năng giả mạo chữ ký bản rõ do lỗi xử lý byte NULL
  • Radix64 Line-Truncation Enabling Polyglot Attacks
    • Việc cắt dòng Radix64 cho phép các cuộc tấn công polyglot
  • GnuPG may downgrade digest algorithm to SHA1 during key signature checking
    • Thuật toán băm có thể bị hạ xuống SHA1 trong quá trình kiểm tra chữ ký khóa
  • GnuPG Trust Packet Parsing Enables Adding Arbitrary Subkeys
    • Quá trình phân tích trust packet có thể cho phép thêm các subkey tùy ý
  • Trusted comment Injection (minisign)
    • Lỗ hổng chèn trusted comment liên quan đến minisign được nhắc lại trùng lặp

Kế hoạch sắp tới

  • Người vận hành cho biết hiện đang thực hiện bản vá, đồng thời sẽ sớm công bố slide và PoC (mã chứng minh khái niệm)
  • Website hiện ở trạng thái được viết lại tạm thời và hẹn một phiên bản cải thiện hơn vào ngày hôm sau

Ý nghĩa

  • Cho thấy tồn tại nhiều lỗ hổng trải rộng trên toàn bộ cơ chế ký, mã hóa và xác minh độ tin cậy của GnuPG
  • Đây là ví dụ nhấn mạnh sự cần thiết phải tăng cường kiểm chứng độ tin cậy nền tảng và audit mã nguồn cho các công cụ bảo mật mã nguồn mở

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-12-28
Ý kiến trên Hacker News
  • Sau khi các lỗ hổng của GnuPG gần đây được công bố, niềm tin đang bị lung lay. Trong video trình bày tại CCC, các zero-day đã được công khai, và việc một số lỗi bị đánh dấu là “wontfix” khiến nhiều người thất vọng
    • Có ý kiến nói rằng “đã mất niềm tin vào Werner Koch”, và cũng có người hỏi lý do vì sao
    • Có người cho rằng GPG đã là một cuộc chiến vô vọng (lost cause) từ hàng chục năm trước, và những người dùng bảo mật nghiêm túc từ lâu đã chuyển sang các công cụ thay thế tốt hơn
  • Bài viết trên blog GnuPG đã được đăng, nhưng có phản ứng cho rằng thật khó chấp nhận việc vẫn duy trì một tính năng đã bị xem là “có hại” suốt 30 năm
    • Một người dùng tiếc nuối nói rằng Werner Koch đã cống hiến cho GPG trong thời gian dài, nhưng giờ đây những khiếm khuyết cấu trúc không thể sửa tận gốc đã lộ rõ
  • Một số lỗ hổng liên quan đến GPG là vấn đề “văn bản không đáng tin cậy có chứa ANSI escape code”, và có ý kiến cho rằng nó giống như XSS phiên bản terminal
  • Cũng có phân tích cho rằng chính cấu trúc packet của GPG quá phức tạp
    • Thông điệp được cấu thành từ nhiều dạng packet khác nhau, nên kẻ tấn công có thể làm nhiễu state machine
    • Đặc biệt, malleability bug gây ra vấn đề bỏ sót bước kiểm tra xác thực do lỗi chuyển trạng thái
    • Sự phức tạp mang tính cấu trúc này tạo ra một “Weird Machine”, và cần được thiết kế lại bằng một định dạng nhị phân đơn giản, rõ ràng hơn
    • Cũng có phản hồi rằng phần giải thích này rất xuất sắc
  • Thảo luận về việc GPG có tuân thủ tiêu chuẩn hay không cũng tiếp diễn
    • Có người nói “đây chỉ là vấn đề của GnuPG, tách biệt với tiêu chuẩn OpenPGP”, nhưng người khác chỉ ra rằng các lỗ hổng parser cũng đã được phát hiện trong các triển khai PGP lớn (Sequoia, minisign, age, v.v.)
    • Một người dùng khác giải thích rằng phe OpenPGP đang chia thành LiberePGP (GnuPG) và RFC-9580 (Sequoia), mỗi bên theo đuổi cách tiếp cận tối giản và tối đa tương ứng. Họ nhấn mạnh rằng điều quan trọng là tránh một cuộc chiến tiêu chuẩn và duy trì khả năng tương tác
    • Một số người cho rằng vấn đề clearsig là lỗi của chính tiêu chuẩn OpenPGP
    • Người khác thì nói rằng các bug của GPG rốt cuộc bắt nguồn từ vấn đề cấu trúc của giao thức PGP, nên thực chất đây là lỗi ở cấp độ giao thức
  • Liên quan đến chữ ký GPG, có câu hỏi được đặt ra: “Có còn an toàn khi tiếp tục dùng GPG để ký git commit/tag không?”
    • Một người dùng lấy ví dụ về “lỗ hổng bitflip” của GPG và giải thích rằng đây là vấn đề nghiêm trọng cho phép kẻ tấn công thao túng văn bản thuần
    • Một người khác chỉ ra rằng chính cấu trúc dùng chung một khóa cho nhiều ứng dụng đã là rủi ro, và cho rằng an toàn hơn nếu mỗi ứng dụng dùng một khóa riêng
    • Cũng có ý kiến cho rằng các lỗ hổng lần này chưa đến mức tấn công từ xa, nên cần sử dụng thận trọng thay vì hoảng loạn
    • Một người dùng chia sẻ kinh nghiệm rằng sau khi dùng GPG và YubiKey trên nhiều thiết bị, họ đã chuyển sang 1Password SSH agent và thấy mọi thứ đơn giản hơn nhiều
    • Người khác nhấn mạnh rằng để thay thế GPG hoàn toàn thì phải giải quyết được bài toán phân phối khóa. Họ chỉ ra rằng khó hơn cả việc ký là cách phân phối khóa công khai một cách đáng tin cậy
  • Cũng có lo ngại về xu hướng dùng giấy phép MIT một cách quá dễ dãi trong hệ sinh thái Rust
    • Một người dùng nói rằng nhiều trường hợp dùng vì “MIT là mặc định”, và cảnh báo rằng nếu mất đi sự bảo vệ copyleft của GPL3 thì quyền kiểm soát của người dùng có thể suy yếu
    • Một người đồng tình nói rằng trước đây họ dùng MIT, nhưng hiện đang chuyển mọi dự án sang copyleft đầy đủ
    • Người khác phân tích rằng hiện tượng này không chỉ có ở Rust mà còn xuất hiện trong hầu hết các hệ sinh thái ngôn ngữ hiện đại
      • Thực tế các tập đoàn lớn xây đế chế trên mã nguồn do tình nguyện viên đóng góp khiến họ nhìn lại giá trị của copyleft
      • Tuy vậy, trong môi trường mà ràng buộc pháp lý không cho phép dùng GPL, người ta vẫn buộc phải chọn giấy phép permissive vì lý do thực tế
      • Mozilla Public License có thể đã là một điểm trung gian nhờ dạng copyleft yếu, nhưng họ tiếc rằng FSF đã không thúc đẩy nó đủ mạnh
    • Có người cho rằng “trong thời đại mã nguồn bị thực thể phi nhân loại (LLM) học, cần một loại giấy phép mới lấy con người làm trung tâm”
    • Người khác nói rằng “dù là GPL hay MIT thì rốt cuộc kiểm soát việc sử dụng cũng chỉ là một tính năng (feature)”, nhìn logic kiểm soát của phần mềm tự do từ góc độ chức năng
    • Một người dùng để lại ý kiến thực tế rằng “rốt cuộc, để phần mềm sống lâu thì trước hết phải sửa bug”
  • Cũng có người vẫn thấy GPG hữu ích
    • Khi dùng cùng thẻ thông minh OpenPGP hoặc YubiKey, nó khá ổn định và dễ thiết lập hơn các giải pháp phần cứng khác
    • Họ dự định sẽ tiếp tục dùng nó cho sao lưu mã hóa, trình quản lý mật khẩu, quản lý khóa SSH hơn là cho email