IngressNightmare: CVE-2025-1974 リモート・コード実行の脆弱性と対策

2025年5月、IngressNightmareと名付けられた重大なセキュリティ脆弱性CVE-2025-1974が公開され、クラウドネイティブインフラに広く展開されているKubernetesのingress-nginxコントローラに影響を与えました。この脆弱性は、認証されていない攻撃者がNGINXに任意の設定を注入することを可能にし、不正なRCE（リモートコード実行）やクラスタの完全な侵害につながる可能性があります。

OPSWAT フェローシップ・プログラムの一環として、フェローたちは、この深刻度の高い問題を取り巻く根本原因、悪用経路、緩和策をよりよく理解するために、徹底的な技術分析を行った。

1. 各設定は解析され、generateTemplateに渡され、定義済みの NGINX テンプレートに従ってフォーマットされます。
2. その後、testTemplateは基礎となる NGINX バイナリに対して生成された構成を検証します。

すべてのNGINXの設定は、ingress-nginxソースコード内のnginx.tmplファイルにある定義済みのテンプレートに基づいています：

generateTemplate関数内で、コンフィギュレーションは以下のコード・スニペットのように処理されます：

しかし、入力検証とサニタイズは不十分です。具体的には、Ingress オブジェクトのuidフィールドが NGINX 構成テンプレートに直接挿入され、インジェクションポイントが作成されます。攻撃者は、uid="1234#; \n}n}n injection_value "のような細工した入力を供給することで、これを悪用できます。

この悪意のある入力により、NGINX テンプレートへのグローバルスコープインジェクションが可能になり、攻撃者は任意の NGINX ディレクティブをトリガーして RCE を達成できる可能性があります。

この脆弱性を悪用するには、攻撃者は悪意のあるコードを実行できるディレクティブを特定する必要があります。なぜなら、このディレクティブはNGINXが外部プラグインをロードすることを可能にするからである。しかし、このディレクティブは設定解析の初期段階でのみ許可されており、今回のインジェクションポイントとは一致しません。

この課題を解決するため、さらに調査を続けた結果、ssl_engineディレクティブにたどり着いた。これは、モジュールを動的にロードする機能によって好奇心を引き起こし、より深い調査が必要となった。

起動時にNGINXは初期状態をロードし、設定ファイルを一行ずつ解析します。各ディレクティブはnginx_command_t構造体で処理され、ssl_engineディレクティブはngx_openssl_commands を直接呼び出します。

ngx_openssl_commands関数を分析したところ、この関数はOpenSSLのサポート、特にハードウェアアクセラレーションSSLモジュールに使用されるENGINE_by_id関数に依存していることがわかりました。

そして、ENGINE_by_id関数を分析するうちに、この関数が共有ライブラリーのダイナミック・ロードを可能にしていることがわかった。さらに、ライブラリが__attribute__((コンストラクタ))拡張でコンパイルされている場合、関連する関数はロード時に即座に実行することができる。これは、ssl_engineディレクティブを悪用することで、攻撃者がホスト上で任意の共有ライブラリをロードし、RCE を引き起こす可能性があることを示している。

デフォルトでは、受信リクエストが8KBを超えると、NGINXは/tmp/nginx/client-bodyにある一時ファイルにリクエストボディを書き込みます。これらの一時ファイルは、受信したメッセージのチャンクが成功するまでの間、最大60秒間保持されます。

リクエストボディの一部を一時ファイルに書き込んだ後、NGINXはボディ全体を受信するまで削除を延期します。リクエストが不完全なままで、最大60秒間データが受信されない場合、ファイルは最終的に消去されます。しかし、最後のデータチャンクを意図的に保留することで、攻撃者は一時ファイルを使用し続けることができ、悪用が可能になります。

アップロードされたファイルの内容を制御することはできるが、ファイル名が ランダムに生成されるため、ファイルシステム上でそれを見つけるのは難しい。保存パスはclient_body_temp_pathを使って設定できるが、ファイル名は実行時にランダムに生成されるため、予測不可能である。このランダム性は、ブルートフォース（総当たり）を使ったとしても、標的を絞ったアクセスを著しく妨げる。これを克服するために、チームはLinux OSに固有の動作を利用した。次の例を考えてみよう：

This code opens a file and keeps it in an active state, closely mimicking the behavior of NGINX's client body buffer mechanism. Using /proc/{pid}/fd directory, attackers can find symbolic links created by the Linux kernel that map open file descriptors to their corresponding file paths. This route allows attackers to reduce the brute-force space to only two variables: the process ID (pid) and the file descriptor (fd).

コンパイル後、出来上がった共有ライブラリのサイズは快適に8KBを超え、追加のパディングを必要とせずにNGINXでバッファリングできるようになった。

そして、サイズの不一致を引き起こすために、Content-Lengthの値を膨らませたリクエスト（例えば、1MB）を作成した。これによりNGINXはボディ全体を即座に処理するのではなくバッファリングし、共有オブジェクトが予測可能な場所に書き込まれるようにした。

RCE を成功させるには、ssl_engineディレクティブがバッファリングされたファイルへの 正しいパスを参照する必要がある。これは、バッファされた共有オブジェクトを指す有効なシンボリックリンクを特定するために、プロセス ID とファイル記述子の可能な組み合わせを系統的に反復する自動化された総当たりスクリプトによって達成できる。

以下は、エクスプロイトのトリガーとなったNGINXテンプレートの生成サンプルです。

悪用に成功すると、攻撃者はingress-nginxポッドのコンテキスト下でシェルアクセスを得ることができる。