GitのキャリッジリターンおよびクローンRCE脆弱性

 (dgl.cx)
1 ポイント 投稿者 GN⁺ 2025-07-09 | 1件のコメント | WhatsAppで共有
  • Gitリポジトリ内のキャリッジリターン文字を利用した攻撃手法を紹介
  • この脆弱性により リモートコード実行（RCE）の可能性 が発生
  • 特定の git clone プロセス で悪意のあるコマンドが実行される
  • LinuxおよびWindows環境 で影響を確認
  • セキュリティ的に 脆弱なGitリポジトリ管理 の危険性を強調

キャリッジリターン文字とGit脆弱性

  • Gitリポジトリ内部に キャリッジリターン（\r）文字を含むファイル名 を作成できる
  • このようなファイル名を含むリポジトリを git clone で複製すると、コマンド解釈の過程で 意図しないコマンド実行 が可能になる

リモートコード実行（RCE）シナリオ

  • 攻撃者はキャリッジリターン文字が挿入されたファイルを追加してリポジトリにコミットする
  • ユーザーがこのリポジトリを git clone すると、ファイルシステムおよびGitコマンドの誤った解釈により 望まないコード実行 の危険が生じる
  • 特に、フックスクリプト（例: .git/hooks フォルダ内のコード）が自動実行されるよう誘導できる

影響環境と対応

  • LinuxおよびWindows など、さまざまなOS上のGitで発生する可能性がある
  • Gitリポジトリを管理したり、外部リポジトリを頻繁にクローンしたりする開発者や企業にとって 深刻なセキュリティ脅威 となる

セキュリティ勧告

  • 外部の信頼できないGitリポジトリをクローンする際は、最新バージョンの使用とセキュリティ状態の確認 が必要
  • リポジトリ内で特殊文字（特に キャリッジリターン など）を含むファイル名を検知し、クローン前に確認する必要がある

関連記事

1件のコメント

 
GN⁺ 2025-07-09
Hacker Newsの意見

  • これらすべての結果として、サブモジュールのクローンを行う際に、読み取りでは path = ... の形で扱う一方、書き込み時には末尾が ^M で終わらない別のパスに記録される現象が発生するという説明

    • 記事で言う「リモートコード実行」がここでどのように起きるのか、またセキュリティ上どれほど深刻なのかという疑問を提起

    • まだ PoC は公開されていないが、CVE-2024-32002 のエクスプロイトをほぼそのまま変形した内容であり、それを修正したコミットのテストも大きなヒントになると言及

    • CVE-2024-32002 の説明を引用: サブモジュール入りのリポジトリを悪意を持って細工し、Git のバグを利用して、サブモジュールのワークツリーではなく .git/ ディレクトリにファイルを書き込める。これにより、クローン動作中に即座に実行される hook を書けるため、ユーザーは実際に実行されるコードを確認する機会すら持てない状況があり得る

    • 要するに、悪意ある git hook をリポジトリに仕込めるのであり、通常は git hook は git clone 時にはインストールされないが、今回の攻撃ではそれが可能になり、クローン中に hook が実行される可能性があるということ

    • 新しい CVE についての詳細は こちら で確認できる案内

      • 設定値を読み取る際、Git は CR と LF を除去するが、書き込む際には CR をエスケープしないため、読み取り時に失われる問題を説明
      • サブモジュールのパス末尾に CR 文字が含まれる場合、除去後のパスが使われるため、サブモジュールが誤った位置にチェックアウトされる可能性
      • その除去後のパスとサブモジュールの hook ディレクトリの間に既存の symlink がある場合、攻撃者は post-checkout hook によって任意コードを実行できる可能性
      • 今回の CVE 以外にも多くの Git 脆弱性があるので、あわせて見る価値があるという意見

    • 任意ファイル書き込みが可能なら、たいていは RCE にまでつながり得るという、単純だが不都合な真実に言及

  • ad-hoc な DSL で設定ファイルを書くことの危険性に言及

    • 文法の正式な仕様がないことが多く、パースに関する本当の基準が自作のシリアライズ/デシリアライズ実装に分散していると指摘

    • 両者がずれると（たとえば、パーサーには新しい文法を追加したのにライターには反映できていない場合など）、パーサー差異によって爆弾になり得ると強調

    • 教訓は、1つの source of truth を置き、それに依存する部分はそれを基に自動生成する構造が必要だということ

    • このバグは source of truth の問題とは別だという指摘

      • 純粋なロジックエラーであり、もし Unix にこうした標準システムライブラリがあれば、そこでも同じように起きていたはずの問題だと説明
      • もしそのような標準ライブラリにあったなら、影響ははるかに深刻だったはずで、今は主に開発者に限られるため被害が比較的小さい状況だと述べる

    • ここで使われている DSL（ini ファイル形式）は ad-hoc ではあるが、非常に一般的で馴染み深く、よく整理されているので、通常は事実上の仕様として十分だという意見

      • バグの本質はフォーマットではなく、その途中に入った手書きのパーサー（またはレキサー）にあり、この種のコードはもうやめるべきだと主張
      • Clever に手書きする必要がある場面はまだ一部に残っているが、データ交換フォーマットには絶対に使うべきではなく、ini が必要なら toml、そうでなければ JSON、YAML でもよく、本当に苦しみを求めるなら XML、どうしてもバイナリ形式が必要だと言い張るなら protobufs だと案内
      • 結論として、プログラミング言語の作者でない限り自分でパーサーを書くべきではなく、必ずライブラリを使うべきだと強調

  • 実際に問題を再現し、このリポジトリ に公開した

    • すぐに git の最新版へ更新しようとしたが、まだ Arch には反映されていない

    • 新しいパッチが出るまでは pull を控えるつもりで、自動 pull が設定されている有名なリポジトリで問題が起き得るので、アップグレードにはかなり時間がかかりそうだという懸念

    • この脆弱性はパッチ前に公開されたのかという疑問を提起

      • 以前は、誰かが脆弱性の悪用方法を説明する記事の大半は、パッチが出て数か月後に掲載されていたが、最近はどの投稿でも「これは本当に今危険だ」と「すでにパッチ済みで心配ない」を明確に区別して、さらっとでも触れてほしいという気持ち

  • 既存エクスプロイトを「簡単に変形しただけ」との言及を見て、Git がなぜ Landlock を使わないのか疑問を提起（Landlock は Linux 専用のサンドボックスセキュリティ機能）

    • git clone は config ディレクトリを読み取り専用、クローン先ディレクトリを読み書き可、さらに子プロセス呼び出し禁止という構成が必要だと提案

    • エクスプロイトが毎回必ず電卓を起動するのはお約束すぎると皮肉る

    • 子プロセス呼び出しを禁止すると、post-checkout などすべての git hook が壊れるという指摘

      • それが不要なら seccomp のようなコンテナ環境で git を実行することもできるが、多くの機能が制限されるだろうと説明

    • さらに、子プロセスがなければ ssh 経由の git 利用もできなくなる点を指摘

  • Homebrew 自体が問題になるのか、つまり recursive clone をしているのかという質問を提起

    • このコード にその可能性を見つけた

    • Homebrew の目的自体がリポジトリのコードを実行することなので、recursive clone がなければむしろ不自然なくらいだという意見

      • 問題は、クローンしたデータが実行されてはいけない場合にのみ RCE が意味を持つので、そういうケースはまれだと指摘

  • Jon Postel の CR+LF に関する有名な言葉を見て懐かしさを覚えた

    • この文章 へのリンクと、2003年と比べると今ではその助言は正しくないかもしれないという評価を共有
    • Mark Crispin が当時解説していたように、人々は誤解しており、1990年代末に Daniel J. Bernstein が人間と機械の間の変換（parsing/quoting）過程で生じる問題を指摘していた事例と結び付ける
    • 25年経っても CR を escape しない quoter のコード問題が繰り返され、修正後でさえ whitespace 全体をチェックしていない点を観察
    • git blame の結果、問題のコードは19年前に書かれたもので、Bernstein の10周年回顧と時期が重なっている
    • 関連コミット、qmail 論文 など追加資料を共有
    • 結局、20世紀に苦労して学んだ教訓を、21世紀になっても繰り返し学ばなければならない現実を強調

  • Homebrew に git 2.50.1 の更新がまだ来ていないので、もう少し待つ必要がありそう

    • この issue または brew install git --HEAD で更新を試す案内

  • Homebrew と Debian Bookworm の両方が、依然として脆弱なバージョンを提供しているという事実を共有

    • もう Homebrew でも 2.50.1 が使えるようになったと通知

  • ディレクトリ一覧を取得するシステムコールが、ファイル名に ASCII 制御文字（bytes）が存在する場合、そのファイルの存在を否定すべきなのか、ディスク破損と見なすべきなのか、それとも別の処理をすべきなのか考える

    • 現在のロケールではそれらのバイトが別の意味を持つ可能性もあり、Windows のようにファイル名をすべて UTF-16 と仮定しているわけではないため、意外な状況が起こり得ると示唆

    • Unix 系システムではファイル名（およびその他の文字列）は単なるバイト配列であることに起因する問題だと簡潔に指摘