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}\n injection_value"。

此惡意輸入允許全局範圍注入到 NGINX 模板，使攻擊者能夠觸發任意 NGINX 指令，並可能達到 RCE。

要利用這個漏洞，攻擊者需要找出一個能夠執行惡意程式碼的指令。最初，我們的研究員發現load_module指令可能有用，因為此指令允許 NGINX 載入外部外掛程式。然而，此指令僅允許在配置解析的早期階段使用，與我們的注入點並不相符。

為了解決這個難題，我們繼續深入研究，結果發現了ssl_engine指令，其描述為「在配置測試期間，該模組可能會被 OpenSSL 動態載入」。這引起了我們的好奇心，因為它具有動態載入模組的能力，因此有必要進行更深入的研究。

啟動時，NGINX會載入初始狀態，然後逐行解析配置檔案。每條指令都由nginx_command_t結構處理，其中ssl_engine指令直接調用ngx_openssl_commands。

在分析ngx_openssl_commands函式時，我們的研究員發現它依賴 OpenSSL 支援，特別是用於硬體加速 SSL 模組的ENGINE_by_id函式。

而在分析ENGINE_by_id函式時，我們確定它可以啟用共用函式庫的動態載入。此外，如果函式庫是以 __attribute__((constructor)) 擴充欄位編譯的，則在載入時可立即執行相關的函式。這表示利用ssl_engine指令，攻擊者可以在主機上傳入任意的共用程式庫，可能導致 RCE。

預設情況下，當接收到的請求超過 8KB 時，NGINX 會將請求體寫入一個位於 /tmp/nginx/client-body 的臨時檔案，使用的檔案名稱格式為 cfg-{random_value}。這些臨時檔案在成功接收訊息的大塊之間最多保留 60 秒。

將部分請求正文寫入臨時檔案後，NGINX 會延遲刪除，直到收到完整的正文為止。如果請求仍未完成，且在長達 60 秒的時間內未收到任何資料，則檔案最終會被清除。然而，攻擊者可藉由故意保留最後一大塊資料，讓臨時檔案繼續使用，使它成為可利用的漏洞。

雖然上傳的檔案內容可以控制，但由於檔案名稱是隨機的，因此在檔案系統上定位檔案是很困難的。儲存路徑可以使用client_body_temp_path 設定，但檔案名稱是在執行時隨機產生，因此無法預測。這種隨機性大大妨礙了目標存取，即使是透過暴力手段。為了克服這個問題，研究團隊利用 Linux 作業系統的固有行為。考慮以下範例：

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 pod 的情境下取得 shell 存取權限，而該 pod 預設可存取敏感的 Kubernetes 群集機密。