Gpg.fail

 (gpg.fail)
4 ポイント 投稿者 GN⁺ 2025-12-28 | 1件のコメント | WhatsAppで共有
  • GnuPGに関する複数のセキュリティ脆弱性を公開したウェブサイトで、各脆弱性の詳細説明ページへのリンクを掲載
  • サイトにはPGP署名、暗号化、信頼検証の過程で発生するさまざまな問題事例が列挙されている
  • 主な項目には平文攻撃、パストラバーサル、ハッシュ計算エラー、メモリ破損、署名偽造などが含まれる
  • 運営者はサイトを急ぎで書き直しており、スライド・PoC・パッチを近日公開予定だと述べている
  • オープンソースのセキュリティツールにおける署名の完全性と信頼体系について、深刻な検証の必要性を示す事例

サイト概要

  • gpg.failは**GnuPG(OpenPGP実装)**の脆弱性をまとめて公開するサイトとして構成されている
    • 各項目は個別リンクで詳細な技術分析ページにつながっている
    • 運営者は「サイトのソースコードを家に置いてきてしまい、書き直し中なので、明日はもっと良いバージョンを期待してほしい」と述べている
  • サイト上部には**"Slides, pocs and patches soon!"**という文言があり、今後の資料公開を予告している

公開されている主な脆弱性一覧

  • Multiple Plaintext Attack on Detached PGP Signatures
    • 分離されたPGP署名に対して多重平文攻撃が可能であると指摘
  • GnuPG Accepts Path Separators and Path Traversals in Literal Data "Filename" Field
    • GnuPGがリテラルデータのファイル名フィールドでパス区切り文字とパストラバーサルを許容する
  • Cleartext Signature Plaintext Truncated for Hash Calculation
    • ハッシュ計算時に平文が切り詰められる問題が発生
  • Encrypted message malleability checks are incorrectly enforced causing plaintext recovery attacks
    • 暗号文の可変性検証が不正確に行われ、平文復元攻撃が可能になる
  • Memory Corruption in ASCII-Armor Parsing
    • ASCII-Armorのパース中にメモリ破損が発生する可能性
  • Trusted comment injection (minisign)
    • minisignでtrusted commentの注入が可能な恐れ
  • Cleartext Signature Forgery in the NotDashEscaped header implementation in GnuPG
    • NotDashEscapedヘッダー実装で平文署名の偽造が可能な恐れ
  • OpenPGP Cleartext Signature Framework Susceptible to Format Confusion
    • **署名フォーマットの混同(format confusion)**に脆弱
  • GnuPG Output Fails To Distinguish Signature Verification Success From Message Content
    • 署名検証の成功可否とメッセージ内容を区別できない出力上の問題
  • Cleartext Signature Forgery in GnuPG
    • NULLバイト処理の不具合による平文署名偽造の可能性
  • Radix64 Line-Truncation Enabling Polyglot Attacks
    • Radix64の行切り詰めによりポリグロット攻撃が可能
  • GnuPG may downgrade digest algorithm to SHA1 during key signature checking
    • 鍵署名検証中にハッシュアルゴリズムがSHA1へダウングレードされる可能性
  • GnuPG Trust Packet Parsing Enables Adding Arbitrary Subkeys
    • 信頼パケットのパース過程で任意のサブキー追加が可能
  • Trusted comment Injection (minisign)
    • minisign関連のtrusted comment注入脆弱性が重複して記載されている

今後の予定

  • 運営者は現在パッチ作業中で、スライドとPoC(概念実証コード)を近日公開する予定
  • サイトは暫定的に書き直された状態で、翌日に改善版を予告している

意味

  • GnuPGの署名・暗号化・信頼検証体系全般にわたる脆弱性が多数存在することを示している
  • オープンソースのセキュリティツールに対する基本的な信頼性検証とコード監査の強化の必要性を強調する事例

関連記事

1件のコメント

 
GN⁺ 2025-12-28
Hacker Newsの意見
  • 最近のGnuPGの脆弱性公表を受けて、信頼が揺らいでいる。CCCの発表動画ではゼロデイが公開され、一部が「wontfix」とされていたことに失望する反応があった
    • 「Werner Kochへの信頼が失われた」という声があり、その理由を尋ねる人もいた
    • GPGはすでに何十年も前から**見込みのないもの(lost cause)**であり、本気でセキュリティを重視する利用者はすでにより良い代替ツールへ移行した、と述べる人もいた
  • GnuPGのブログ記事が公開されたが、30年間「有害と見なされてきた」機能をいまだに維持しているのは納得しがたい、という反応があった
    • あるユーザーは、Werner Kochが長年GPGに尽くしてきたことは認めつつも、今や根本的に修正できない構造的欠陥が露呈したことを惜しんでいた
  • GPG関連の脆弱性の一部は「ANSI escape codeを含む信頼できないテキスト」の問題で、まるでターミナル版のXSSのようだという意見があった
  • GPGのパケット構造自体が過度に複雑だという分析もあった
    • メッセージが複数形式のパケットで構成されているため、攻撃者が状態機械をかく乱できる
    • 特にmalleability bugは、状態遷移の誤りによって認証検証が抜け落ちる問題を引き起こす
    • こうした構造的複雑さが「Weird Machine」を生み出しており、単純で明確なバイナリ形式に再設計すべきだという主張だった
    • この説明が素晴らしいという反応もあった
  • GPGの標準準拠性をめぐる議論も続いた
    • 「これはGnuPG固有の問題であり、OpenPGP標準とは別物だ」と言う人もいたが、別の人は主要なPGP実装（Sequoia、minisign、ageなど）でもパーサー脆弱性が見つかっていると指摘した
    • また別のユーザーは、OpenPGP陣営は**LiberePGP(GnuPG)とRFC-9580(Sequoia)**に分かれており、それぞれミニマリズムとマキシマリズムのアプローチを取っていると説明した。標準戦争を避け、相互運用性を維持することが重要だと強調した
    • 一部はclearsig問題がOpenPGP標準そのものの欠陥だと主張した
    • 別の人は、GPGのバグは結局PGPプロトコルの構造的問題に由来しており、事実上プロトコルレベルのバグだと評価した
  • GPG署名に関連して、「git commit/tagの署名にGPGを使い続けても安全か？」という質問が出た
    • あるユーザーはGPGの「bitflip脆弱性」を例に挙げ、攻撃者が平文を改ざんできる深刻な問題だと説明した
    • また別の人は、単一の鍵を複数のアプリケーションで共有する構造自体が危険だと指摘し、アプリごとに別々の鍵を持つべきだと主張した
    • 他の意見では、今回の脆弱性はリモート攻撃級ではなく、パニックより慎重な利用が必要だと助言していた
    • あるユーザーは、複数のデバイスでGPGとYubiKeyを使っていたが、1Password SSH agentへ移行してずっと単純になったと体験を共有した
    • 別の人は、GPGを完全に置き換えるには鍵配布の問題を解決しなければならないと強調した。署名そのものよりも、公開鍵を信頼できる形で配布する方法のほうが難しいと指摘した
  • RustエコシステムでMITライセンスが何気なく使われがちな傾向への懸念も提起された
    • あるユーザーは「MITがデフォルトだから」という理由で使われることが多いとし、GPL3のコピーレフト保護が失われると利用者のコントロール権が弱まる可能性があると警告した
    • これに同意した人は、以前はMITを使っていたが、今はすべてのプロジェクトを完全なコピーレフトへ切り替えつつあると語った
    • また別の人は、こうした現象はRustに限らず、ほとんどの現代的な言語エコシステムで見られると分析した
      • 大企業がボランティアのコードの上に帝国を築く現実を見て、コピーレフトの価値を再認識するようになった
      • ただし法的制約によりGPLを使えない環境では、実用的な理由で寛容なライセンスを選ばざるをえないとも述べた
      • Mozilla Public Licenseのような弱いコピーレフトが中間点になり得たが、FSFがこれを十分に後押ししなかったのは残念だという意見もあった
    • ある人は「非人間（LLM）がコードを学習する時代には、人間中心の新しいライセンスが必要だ」と主張した
    • 別の人は「GPLであれMITであれ、結局**使用制御もひとつの機能(feature)**にすぎない」として、自由ソフトウェアの統制論理を機能的な観点から捉えていた
    • あるユーザーは「結局ソフトウェアが長く生き残るには、まずバグを直すことが先だ」と現実的な意見を残した
  • それでもGPGを依然として有用に使っている人もいた
    • OpenPGPスマートカードやYubiKeyと組み合わせればかなり安定しており、他のハードウェアソリューションより設定もしやすい
    • メールよりも、暗号化バックアップ、パスワードマネージャー、SSH鍵管理などで引き続き使うつもりだ