ハクソク

世界を動かす技術を、日本語で。

Gpg.fail

110日前原文(gpg.fail)

概要

GnuPGやminisignなどの暗号ツールにおける複数の脆弱性について解説。
攻撃手法や影響範囲、具体的な脆弱性例を箇条書きで整理。
各問題点ごとに分かりやすく要点をまとめる。
セキュリティ上の注意点や対策の必要性を強調。
実際の攻撃例や影響を簡潔に紹介。

GnuPGおよび関連ツールにおける主な脆弱性

  • Multiple Plaintext AttackによるDetached PGP Signatureの脆弱性

    • 複数の平文を利用した署名検証の回避
    • 署名の信頼性低下リスク

  • GnuPG Accepts Path Separators and Path Traversals in Literal Data "Filename" Field

    • ファイル名フィールドにパス区切り文字やディレクトリトラバーサルを許容
    • 任意のパスへのファイル書き込みや情報漏洩の危険性

  • 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における信頼コメントのインジェクション
    • 偽の信頼情報付与や混乱の恐れ

  • Cleartext Signature Forgery in NotDashEscaped header implementation in GnuPG

    • NotDashEscapedヘッダー実装における署名偽造
    • 攻撃者による不正署名作成の可能性

  • OpenPGP Cleartext Signature Framework Susceptible to Format Confusion

    • フォーマット混乱を利用した攻撃
    • 署名・メッセージ内容の誤認リスク

  • GnuPG Output Fails To Distinguish Signature Verification Success From Message Content

    • 署名検証結果とメッセージ内容の区別不能
    • ユーザーが誤認しやすい仕様

  • Radix64 Line-Truncation Enabling Polyglot Attacks

    • Radix64エンコーディング時の行切り捨て
    • 複数形式ファイル（polyglot）による攻撃

  • GnuPG may downgrade digest algorithm to SHA1 during key signature checking

    • 署名検証時にハッシュアルゴリズムがSHA1へダウングレード
    • 安全性の低いアルゴリズム利用によるリスク

  • GnuPG Trust Packet Parsing Enables Adding Arbitrary Subkeys

    • Trust Packet解析時に任意サブキー追加可能
    • 鍵管理の信頼性低下

セキュリティ上の注意点と対策

  • 常に最新バージョンのGnuPGやminisignを利用
  • 不審な署名やファイル名、コメントの検証徹底
  • 公式アドバイザリやパッチ情報の定期的な確認
  • セキュリティ監査や脆弱性診断の実施

まとめ

  • GnuPGやminisignなどの暗号ツールには多様な脆弱性が存在
  • 攻撃者による署名偽造や情報漏洩、コード実行のリスク
  • 適切なアップデートと運用管理がセキュリティ確保の鍵

Hackerたちの意見

CCCのトークからのゼロデイ情報だね。https://fahrplan.events.ccc.de/congress/2025/fahrplan/event/... でも、Werner Kochへの信頼はもうないな。修正しないのかな？
└
「Werner Kochへの信頼がなくなった」ってどういう意味？もう少し詳しく教えてくれる？
└
正直言って、今の時点でGPGは基本的に数十年も無駄な存在になってる。セキュリティを真剣に考えてる人は、GPGの代わりになる新しい良いツールを使ってるよ。でも、「すべてを支配する一つの指輪」なんてないからね。
サイトがダウンしてるみたい？トークで発表されたエクスプロイトのまとめがあるスレッドを見つけたよ。https://bsky.app/profile/filippo.abyssdomain.expert/post/3ma...
└
サイトが過負荷かもね。「ちょっと待って、今対応中だよ！！！」って言ってたけど、トーク中はこのページでライブストリームが見れたんだ。メディアが投稿したら、録画に差し替えてくれるといいな。数時間以内にはアップされるはず。
これ、ちょっと落ち込むね。サイトがダウンしてる間に集めた情報によると、GnuPGに14個の脆弱性が見つかったみたいで、そのほとんどが未修正なんだって。中にはメンテナが修正を拒否してるものもあるらしい。拒否する理由があるのかもしれないけど、他の人も意見をくれるといいな。これってXKCD-2347のケースなの？それとも他に何かあるのかな？ほとんどのLinuxディストリビューションはPGPがかなり安全であることに依存してるし、IBMとかも余裕のある開発者や資金を提供できるはずだよね？
└
サイトがダウンしてるからまだ読んでないけど、他のコメントを見る限り、クリアテキスト署名に関する問題みたい。昔のメーリングリストのアーカイブ以外では見たことないな。今はみんな、メール用にPGP/MIMEみたいな分離署名を使ってるし。
└
> 確かにIBMやその関連企業には、余剰の開発者や余剰の資金があるはずだよね？ GPGの問題の大部分は、資金や開発者の時間ではない。根本的に暗号使用に対する悪い設計なんだ。あらゆるユーザーやユースケースに対応しようとするあまり、開発者やユーザーの足元をすくうようなものになってしまっている。これを解決するには、代替の目的特化型ツールに移行することだね。メッセージングにはSignalやWhatsApp、ファイル暗号化にはage、署名にはminisignなど。
└
「ほぼすべてのLinuxディストリビューションがPGPの安全性に依存している」と言っているなら、Linuxのパッケージマネージャーでパッケージに署名するための使い方を指しているのだろうけど、彼らはPGPをかなり制約された方法で使っていることに注意が必要だ。特に、データは信頼できるサーバーからHTTPS経由でダウンロードされるため、すでに信頼されていることが多い（そのためPGPが冗長になっている部分もある）。だから、ほとんどのPGPの脆弱性は彼らには影響しない。もしPGPの脆弱性が実際にRHELやFedoraシステムに無許可の更新を押し込むことを可能にするものであれば、たぶんIBMは気にするだろうけど、もしPGPのセキュリティ問題が深刻な脅威だと結論づけたら、PGPを安全にするために投資を始めるよりも、PGPからの移行を始める可能性が高いと思う。前者の方が対処しやすく、保守性の利点もあるしね。
AFAICT、これはGnuPG特有の問題でOpenPGPとは関係ないのかな？GnuPGは規格準拠から外れちゃったし、もっと良い選択肢がたくさんあるよ。Sequoia chameleonなんかは、ほとんどのワークフローに対応したツールもあるし。
└
主要なPGP実装のすべて、GNU PGPだけじゃなくて、sequoia、minisign、ageにも重大なパーサーの欠陥があることが示されたんだ。でも、私たちにはgpgが一番印象が悪かった。修正しないってことだね。
└
いや、clearsigの問題はopenpgp標準自体にあるんだよ。
└
特定のバグはGPGに関するものだけど、そもそもそれらが存在する理由の多くはPGPの複雑なアーキテクチャにあると思う。私の意見では、こういった問題は避けられないプロトコルバグだ。
└
オープンPGPの標準における二つの派閥の対立について、コンセンサスのアイデアから離れていると言った方が、もっと正確で役に立つと思う。ここには根本的な哲学の違いがある。LiberePGP派（GnuPGP）は、標準の変更や追加に関して伝統的なPGPのミニマリズムに従っている。一方、RFC-9580派（Sequoia）は、あらゆる潜在的な問題が変更や追加につながるようなマキシマリストのアプローチを取っている。幸運なことに、現在の標準に特に問題がないことが分かったので、今はそれを続けて、標準戦争を回避できる。そうすれば、さまざまな実装間での相互運用性が確保できる。もし何かの弱点が見つかって、実際に標準の変更が必要になったら、コンセンサスを見つけるのはずっと簡単になると思う。
GnuPGのWerner Kochが最近（2025年12月26日）ブログにこれを投稿したよ。https://www.gnupg.org/blog/20251226-cleartext-signatures.htm... アーカイブリンク: https://web.archive.org/web/20251227174414/https://www.gnupg...
└
なんか物足りない感じがするね。「有害だと考えられている」ものが30年も続いてるなら、責任あるエコシステムの中で廃止されて、取り除かれるべきだと思う。(PGP/GPGは、自らがスイスアーミーナイフ的な存在で、セキュアな運用からは緩やかに結びついている決定に足を引っ張られてるから、さらに責任ある行動として、セキュリティ特性を提供できない目的には捨てるべきだよ。ほとんどの用途でね。)
└
ウェルナー・コッホは大変だろうな。GPGにこんなに時間とエネルギーを注いできたのに、何度も無能さを示されて、GPGが根本的に修正不可能な状態だってことが分かるなんて。
書き込みが公開されて、録音はここにあるよ：https://media.ccc.de/v/39c3-to-sign-or-not-to-sign-practical...
ここには消化するべき情報がたくさんあって、GnuPGのメンテナが「修正しない」と指定した問題もあるみたいだけど、gpgの署名をgitのコミットやタグに使うのは脆弱なのか、もっと詳しい人に教えてもらえない？今後のためにもっと良い代替手段はあるのかな？SSHキーでの署名は今はもっと安全だと考えられてるの？できればgpgを生活から排除したいけど、自分の名前が入ったコミットやタグが本当に自分から来てるか確認したいんだよね。
└
今年、また新しいパソコンを手に入れたのをきっかけに切り替えたよ。合計で4台あるんだ（仕事用ノート、個人用ソファノート、Mac Mini、Linuxタワー）。gpgと常駐SSHキーでYubiキーを使ってたけど、すべてのマシンで動かすための設定が必要だった。細かいことを忘れがちで、公開鍵をキーチェーンに取り込むスキルを再学習しなきゃいけなかったんだ。1PasswordのSSHエージェントとgitのSSH署名に移行することで、これらをすべて解消したよ。SSHの設定から多くの頭痛が消えた。ただ、特定のウェブサービス用にYubiキーは2要素認証としてまだ使ってるけどね。gpgエージェントはまだ動いてるけど、今はバックアップ用としてだけ。来年にはこれをオフにするつもり。
└
これらは「リモートエクスプロイト」の意味での脆弱性ではない。真剣に受け止めるべきで、信頼できないデータでローカルソフトウェアを実行しないように気をつけるべきだし、GPGはユーザーが自分を傷つけないようにもっと保護するべきだ。でも、一番悪いのはパニックになって、パートナーや同僚が信頼しているプロセスを捨てることだよ。ここには、コミットに署名したり、ディストリビューションからapt-get installしたりするワークフローを乱すものは何もない。もし暗号コマンドラインツールを使って送られてきたデータを確認するなら、自分が何をしているのかを意識して、ここで示された攻撃を理解することが大事だ。一つのスライドには「コマンドラインツールを使うべきか？」ってタイトルがあって、はい、使うべきだよ。代わりの選択肢はもっと悪いからね。でも、すべての信頼できないデータを敵対的なものとして扱うことに注意しなきゃ。
└
その中の一つのWONTFIXは、異常な脆弱性に関するものだ。PGPメッセージ内の既知の平文をビットフリップして圧縮処理に切り替えることができる。これにより、攻撃者はGnuPGのパケット処理にメッセージ内の任意の位置を参照させることができ、認証失敗メッセージを抑制しながら行える。GPGの立場は、そういう状況では何らかのエラーを表示するからそれで十分というものだ。これは平文バイトを明らかにする攻撃なんだ！
└
特定の場所でアプリケーションが探すことになっている単一のキーを持つのは根本的に悪いアイデアだ。複数のコンテキストでキーを使うことを安全にするには固有の複雑さが伴うから、建築的に避けた方がいい。キー（量子安全なものでも）は小さいから、アプリケーションごとに一つ持つのは全く問題ない。もしアプリケーションが複数のコンテキストを必要とするなら、自分たちで処理できる。もしそれをうまくやれなければ、そのアプリケーションにだけ被害が収まる。もし誰かが「これはジョンスミスのgit用のキーです」とか「これはジョンスミスのメール用のキーです」と署名するだけのアプリケーションを作りたいなら、それもできる。そのアプリケーションは、他のアプリケーションが呼び出すための権限を気にする必要はない。ユーザーは、特定のアプリケーションで自分のアイデンティティを証明したいときに、公開鍵やフィンガープリントをコピー＆ペーストすればいい。キーリングのサーカス（これがGPGが私の生活に最も一般的に介入する方法）は本当にクレイジーだ。すべてのアプリケーションが、秘密を自分のローカルストレージに書き込むのではなく、何らかのGPGキーリングに接続することを要求している。ディスクは完全に暗号化されていて、アプリケーションは互いに隔離されるべきだ。ディスクに書き込む前に、別のプログラムで「追加の暗号化」を要求することで何かが達成されるわけではない。これらの悪いアイデアは、企業の「セキュリティ」サークルで発明された忙しい仕事から来ていると思う。実際の脅威モデルを無視して、人々を雇用し続けるために複雑さを生み出しているんだ。
└
> 「できればgpgを生活から排除したい」と思ってる。こういう意見、よく見るけど、後で問題に触れてるね。どんな「代替品」でも、安全な鍵の配布を解決しないといけない。署名自体は難しくないし、gpg以外でも鍵を使って安全に署名する方法はいろいろあるから。もしgpgのその部分が壊れてるなら、それはバグだし、修正できるはず。実際の課題は、他の誰かがその署名を検証できるように鍵を配布することで、ほとんどの方法は根本的に欠陥があって、運用ミスのリスクを引き起こしたり、面倒だったりする（信頼のウェブ、初回使用時の信頼、中央機関、対面など）。ここでの正しい答えが「新しいものを発明して、その周りのエコシステムを作る」っていうのは納得できないな。
https://media.ccc.de/v/39c3-to-sign-or-not-to-sign-practical...
ここでのいくつかの厄介な脆弱性の共通点は、PGPの異常なパケットシステムにある。PGPメッセージは、制御用とデータ用のほぼ任意のパケットのストリームで、暗号的なバインディングが全く無秩序なんだ。XMLDSIG（攻撃者が制御するタグに従ってXMLメッセージのランダムな場所から暗号制御データを引き出す）とSSL2（完全なハンドシェイクの認証がない）の中間のような感じ。切り離された署名への攻撃（攻撃 #1）は、GnuPGが複雑な状態機械を動かさなきゃいけないから起こるんだ。その中には、3つの異なるスタイルのメッセージ署名が含まれている。GPGでは、その状態機械が「データを見たから署名を確認する必要があるか？」というバイナリチェックに縮小されてしまう。メッセージストリームに異なるパケットを押し込むことで、その条件を選択的に切り替えられるんだ。たとえすでに確認が必要なデータを送信していてもね。可塑性バグ（攻撃 #4）は特に巧妙だ。これもまた、無秩序な状態機械の問題。GPGは、暗号的に無効なパケットを処理できないことがあるんだけど、メッセージのフレーミング自体が壊れている場合もある。後者の非暗号的な失敗は、メッセージの処理を中止することで対処され、GPGはエラーを処理している予期しない状態に入って「メッセージの認証子を確認するのを忘れる」んだ。CBCビットフリップを使って既知のヘッダーを操作して、GPGにDEFLATE圧縮を処理させることができる。そうすると、メッセージを処理することで平文が出力されるようにメッセージを改変できる。フォームフィードバグ（#3）は本当に奇妙だ。GnuPGは `\f` を特別に扱っていて、行の終わりに出現すると、任意の符号なしデータを注入できる。これはGnuPGの行切り詰め処理のためだ。なんでこんな機能があるんだろう？これらの攻撃は状況依存に見えるけど、それは誤解を招く。なぜなら、PGPは（特に古いシステムでは）アプリケーションの暗号化バックエンドとして使われているからだ。マロリーがアリスに何かを署名させたり暗号化させたりするのは、非常に現実的な脅威モデルなんだ（これは安全なクッキーに対するほとんどの暗号攻撃と同じ脅威モデルだ：アプリが自動的にユーザーのために署名をする）。メッセージ暗号化システムがこんな複雑さを持つ理由はない。PGPの深い設計上の欠陥だ。フォーマットには非常にシンプルで直交的な機能が必要で、理想的にはすべてを明確に長さで区切られた不透明なバイナリブロブとして扱うべきなんだ。それなのに、変なマシンができて、こんな話になる。素晴らしい仕事だね。
└
こんな素晴らしい説明をありがとう！
gpgは気に入ってるよ。特にオープンPGPスマートカードやユービーキーベースのプライベートキーでよく使ってる。かなり素晴らしいエコシステムだし、ほとんどのハードウェアスマートカードはたくさんのブラックマジックや秘密のハンドシェイクに囲まれてるから、pkcs#11やopensc/openctは設定がすごく難しい。いろんなことに使ってるけど、メールには使ってない。暗号化バックアップ、パスワードマネージャー、sshキーとかね。fido2みたいな他のハードウェアオプションもあるけど、すべてのユースケースに対応してるわけじゃないし、ユースケースごとに同じものが使えるわけでもない。だから、これからも長い間gpgを使い続けると思うよ。