NGINX Rift - 新しい NGINX エクスプロイト

 (github.com/DepthFirstDisclosures)
1 ポイント 投稿者 GN⁺ 2 시간 전 | 1件のコメント | WhatsAppで共有
  • NGINX Rift は、NGINX ngx_http_rewrite_module に存在する致命的なヒープバッファオーバーフロー CVE-2026-42945 に対するリモートコード実行 PoC
  • この脆弱性により、rewrite と set ディレクティブを使用するサーバーで 認証不要のリモートコード実行 が可能になる
  • 問題は 2008 年に導入されたバグで、NGINX スクリプトエンジンの 長さ計算パス と コピー パス が is_args フラグを異なる形で処理することで発生する
  • rewrite 置換文字列に ? が含まれている場合、メインエンジンでは is_args が設定されるが、長さ計算は新たに 0 で初期化されたサブエンジンで実行されるため、元のキャプチャ長だけが返される
  • コピー段階では is_args = 1 の状態で ngx_escape_uri と NGX_ESCAPE_ARGS が呼び出され、エスケープ可能な各バイトが 3 バイトに拡張されることで、過少割り当てされたヒープバッファが攻撃者制御の URI データによってオーバーフローする
  • エクスプロイトはリクエスト間で ヒープ風水(heap feng shui) を利用して隣接する ngx_pool_t の cleanup ポインタを破壊し、URI バイトには null バイトを含められないため、POST ボディを通じてスプレーを行う
  • 破壊されたポインタは偽の ngx_pool_cleanup_s へとリダイレクトされ、プール破棄時に system() を呼び出すよう構成される
  • CVE-2026-42945 に加え、CVE-2026-42946、CVE-2026-40701、CVE-2026-42934 の 3 件のメモリ破損問題も、depthfirst のセキュリティ解析システムが NGINX ソースを一度オンボーディングしただけで自律的に発見した
  • 影響を受けるバージョンは NGINX Open Source 0.6.27–1.30.0 および NGINX Plus R32–R36 で、修正版は Open Source 1.31.0/1.30.1、Plus R36 P4/R35 P2/R32 P6 とされている
  • 完全なベンダー勧告は https://my.f5.com/manage/s/article/K000160932 にあり、技術的な詳細は technical write-up で扱われている
  • PoC は Ubuntu 24.04.3 LTS 上でテストされており、./setup.sh、docker compose -f env/docker-compose.yml up、python3 poc.py --shell の順で脆弱な NGINX コンテナを起動し、シェルを実行する流れを提供している

関連記事

1件のコメント

 
GN⁺ 2 시간 전
Hacker News の意見

  • セキュリティ担当者として、公開されたエクスプロイトが ASLR 回避をしていないという理由で、この問題はずっと怖くないと断定したり示唆したりする反応が多すぎてうんざりする。
    原文は、この攻撃で ASLR を安定して回避する方法があると主張しており、証拠がなくてもデフォルトの前提として信じるに値すると見ている。
    ASLR はエクスプロイトを難しくする多層防御の手法にすぎず、ほとんどの場合、時間と技量があれば ASLR 回避は追加される。
    LLM エージェントのせいで、その時間と技量の障壁も数週間ごとに下がっており、完全に兵器化されたエクスプロイトが出るのは時間の問題であり、公開されるかもしれないし、非公開のままかもしれない。
    「ASLR を有効にしていれば危険ではない」というのは明らかに誤りであり、そんな言葉を信じる人にとって非常に有害だ。
    緩和策によってエクスプロイトが難しくなるからセキュリティ脆弱性を気にしなくてよい、という誤った思い込みは、すでに過去に大きな被害を生んできた。
    現代的な緩和策があるのは幸運だが、できるだけ早くパッチを当てるべきであり、ベンダーであれば研究者が ASLR 回避を提示していないからといって脆弱性報告を無効扱いせず、根本原因を修正すべきだ。

    • リモートから到達可能な脆弱性は軽く見てはいけない。
      ただし現時点では、前提条件がやや特殊に見える。
      10年間さまざまな構成で nginx を使ってきたが、rewrite と set を一緒に使ったことは一度もない。
    • 「AI がサイバーを解決する」と言う人と、「ASLR を有効にしていれば大丈夫」と言う人は、1:1 で重なっていると見て差し支えない。
      しかも必ず “cyber” と言う。
    • この見方には同意しないか、少なくとも別の表現をしたい。
      ASLR は当てるべき追加のパスワードのようなもので、一定のエントロピーを持ち、通常は安定している。
      脆弱性に情報漏えいの要素がなければ、ASLR はその脆弱性を完全に緩和するか、さもなければ 2 つ目の脆弱性が必要になる。
      それは別の議論だ。
      ASLR は個別の脆弱性を完全に緩和できるが、エクスプロイトチェーン全体までは止められない。
      それでも迅速なパッチ適用を説得するには、情報漏えいを生む 2 つ目の脆弱性の可能性を根拠にするほうがよいと思う。
      エクスプロイトチェーンは、あらゆる種類の脆弱性で危険だ。
    • インターネットで誤情報が広がるのを防ぐのは難しく、ほとんどの人は自分が間違っていることすら知らない。
      本当に有害なのは、自信満々の無作為なインターネット上のコメントをそのまま信じることだ。
      そうしたものを見抜く力を養えば、セキュリティだけでなく他の分野でも役に立つ。
    • 公開インターネットにさらされたソフトウェアのリモートコード実行の報告を読んだら、普通は数分以内にアップグレードする。
      だからこういう報告を読むのであり、真剣に受け止めるべきだ。
      そうしなければ、じきにマシンが侵害される。
      最近は、公開されるリモートコード実行エクスプロイトのうち事前通知なしのものが多いように見え、少なくともソフトウェアをアップグレードする数分くらいは与えてほしい。
      リモートエクスプロイト可能な sendmail バグが相次いでいた 1980 年代末から 1990 年代初頭のように、公開に安全装置がなかった時代のようだ。
      こうした報告を読まない、あるいは読むのが遅すぎると、数百万台が侵害され得る。
      現在 nginx は公開 Web サーバー市場の約 39〜43% を占めているため、かなり深刻だ。

  • 今回の件はかなり悪いが、前提条件がある。
    置換文字列にクエスチョンマークを含む rewrite ディレクティブが必要で、その後に正規表現キャプチャグループを参照する set ディレクティブが続く必要がある。
    例: set $var $1
    さらに概念実証は ASLR 無効化を前提としている。

    • 例: https://github.com/DepthFirstDisclosures/Nginx-Rift/blob/mai...
    • デフォルトで ASLR を無効にするディストリビューションはあるのか。
      手動で無効にするとしても、nginx がその候補として真っ先に思い浮かぶことはない。
    • 最近は rewrite をあまり使わないのでは。
      PHP と Apache の昔の時代に使っていた印象がある。

  • 公式の F5 ページはこちら: https://my.f5.com/manage/s/article/K000161019
    他でも書かれている通り、ASLR が保護してくれる。
    影響を受けるプラットフォーム向けの修正版を待つ間の緩和策として、「rewrite の定義では無名キャプチャの代わりに名前付きキャプチャを使うこと」と案内している。
    「この例で脆弱性を緩和するには、$1 と $2 を適切な名前付きキャプチャである $user_id、$section に置き換えよ」という内容だ。
    F5 は 1.31.0 と 1.30.1 にパッチを適用した。
    OpenResty には 1.27 と 1.29 向けのパッチがある: https://github.com/openresty/openresty/commit/ee60fb9cf645c9...
    Nginx ベースの Lua アプリケーションサーバーである OpenResty の進捗はここで見られる: https://github.com/openresty/openresty/issues/1119

  • 概念実証では ASLR を無効化している: https://github.com/DepthFirstDisclosures/Nginx-Rift/blob/mai...

    • ワーカープロセスはマスターから fork されるので、同じメモリ配置を受け取る。
      ワーカーに対しては無制限にクラッシュを起こせる。
      これを利用して読み取りオラクルを作る方法がある可能性は高い。
      少なくとも安定したサービス拒否は可能だ。
      Depth First の完全な分析: https://depthfirst.com/research/nginx-rift-achieving-nginx-r...

  • Apache や Nginx の良い代替で、メモリ安全な言語で書かれていて、しかもセキュリティホールがあまり多くないものはあるだろうか。
    Java で書かれた Jetty と Go で書かれた Caddy を少し見たが、Jetty にはシェルインジェクションのような別種の脆弱性の履歴もあり、本当により良いのか確信が持てない。

    • メモリ安全性は良いが、すべての脅威を防ぐわけではない。
      今のインフラ運用者は能動的防御である MAC、つまり SELinux や AppArmor に慣れるべきだ。
      昔は摩擦が大きかったが、今は利用を容易にするツールが増えている。
      https://presentations.nordisch.org/apparmor/
      https://github.com/nobody43/apparmor-profiles/blob/master/ng...
      https://github.com/nobody43/apparmor-suggest
      参考までに、両方のリポジトリとも自分で作ったものだ。
    • Apache や nginx 級の規模で使われるソフトウェアなら、どんなものでも脆弱性の履歴があるのは避けられない。
      どちらもこれほど長く市場シェアを維持してきたという事実は、むしろ良い兆候だ。
    • Caddy は本当に使いやすかった。
      ただ、ちゃんとしたプラグインシステムではなく、欲しいプラグインの組み合わせごとに何千ものバイナリが生まれるモデルは少し微妙だ。
      それでも、ソースからビルドするならかなりきれいでシンプルだ。
    • Apache と、おそらく Nginx も、機能と構成要素が非常に多い。
      代替 HTTP サーバーの多くは対象範囲をかなり絞っているので、まずどの機能が必要かを決めるべきだ。
      メモリ安全な言語で書かれた HTTP サーバーの議論はあまり見かけない。
      C ベースの大きな 3 つのサーバー、Apache、Nginx、lighttpd はいずれもかなり堅牢で、単に言語が理由というだけで新しいプロジェクトへ乗り換えようとする人は多くないようだ。
      また、メモリ安全な言語を選ぶと、その言語の、ときに非常に大きなランタイムや仮想マシン、付属要素まで受け入れることになりがちだ。
      Java の Web サーバーなら、よくある適当な Java プロジェクトと同様に log4j を使っている可能性がある。
    • ロードバランサー用途なら HAProxy が非常にうまく機能している。

  • 「エクスプロイトはリクエスト間ヒープ風水 (cross-request heap feng shui) を使う」とは、こういう文脈で feng shui が使われているのを初めて見た。

  • Debian 12 ではこれはパッチ済みなのか。
    それでも、どこでも rewrite や set を使っていなければ影響を受けないと考えてよいのか。

    • https://security-tracker.debian.org/tracker/CVE-2026-42945
    • Ubuntu は今日の朝の時点でパッチ済みだった。
      Debian はまだ trixie をパッチしていないようだ。
    • nginx を使っていて少なくとも set すら使わないケースはかなりまれだと思う。
      たいていの nginx 利用例は TLS を終端し、リクエストを node/php/go などに渡すことだ。
      そのため、proxy_set_header X-Host $host; のような行で、攻撃者が制御するデータが入った set が 1 つくらいはあるだろうと思っていた。
      訂正: 名前付きキャプチャは影響を受けないようだ。
      どこにも $1 がなければ大丈夫そうだ。

  • より良いリンク:
    https://depthfirst.com/research/nginx-rift-achieving-nginx-r... (https://news.ycombinator.com/item?id=48126029)
    https://depthfirst.com/nginx-rift (https://news.ycombinator.com/item?id=48123365)