CVE-2024-5452

01. RCE と pytorch-lightning の概要

1) RCE と pytorch-lightning の概要

RCE（Remote Code Execution、リモートコード実行）は、攻撃者がリモートからシステムやアプリケーション内で任意のコードを実行できるようにする脆弱性であり、CWE-94: Improper Control of Generation of Code ('Code Injection') です。

PyTorch Lightning は、PyTorch ベースのディープラーニングモデルのトレーニングを簡単に管理できるようにするライブラリであり、DeepDiff は 2 つの Python オブジェクトを比較して差分を分析するライブラリです。

CVE-2024-5452 は、Lightning の AI モデル重み関連の Web アプリケーション機能において、DeepDiff と Lightning を利用する過程で、DeepDiff の脆弱なヘッダー検証とデルタ属性の汚染を通じて、逆直列化時に RCE を引き起こす脆弱性です。

これにより、攻撃者が任意のオブジェクトを注入したり、リモートコード実行（RCE）を実行したりできる脆弱性が発生するコードの流れを確認し、これに対する対応策を検討します。

02. pytorch-lightning 環境における逆直列化の脆弱性分析

2.1 DeepDiff に対する Delta 汚染を用いた攻撃分析

pytorch-lightning では、Web アプリケーションソースの DeepDiff エンドポイントのうち /api/v1/delta に delta の属性を汚染して送信することで攻撃できます。
例を見ながら、delta の dunder 属性を汚染して、どのようにオブジェクト逆直列化の脆弱性が引き起こされるのかを確認します。

1) DeepDiff に対する Delta 汚染を用いた攻撃フロー

最初のリクエストは、Client 攻撃例、汚染設定 -> DeepDiff の /api/v1/delta における脆弱なヘッダー検証 -> 汚染設定による状態保存です。

[図1] POC - Endpoint 攻撃

[図2] POC - Vuln Injection / 全体の汚染設定内容

[図3] lightning/api/core/api.py / 脆弱なヘッダー検査ロジック部分

[図4] lightning/api/core/app.py / 設定区間

[図5] lightning/api/core/app.py / 設定保存区間

最初のリクエストは、[図3] の /api/v1/delta のヘッダー検証を [図1] によってバイパスした後、操作した汚染設定（delta）[図2] を注入し、[図4]、[図5] によって設定を保存します。それでは、2 番目のリクエストで、この操作されたデルタの設定がどのように作用するのかを見ていきます。

[図6] lightning/api/core/app.py / 初期パスの流れ
[図6] は、デルタが設定された後の 2 番目のリクエストの流れであり、run_once() -> maybe_apply_change() -> _collect_deltas_from_ui_and_work_queues() です。

[図7] isinstance 汚染ケース
[図7] _collect_deltas_from_ui_and_work_queues() での isinstance 検査を汚染された設定で通過（isinstance(delta, _DeltaRequest) == False）させて、else で動作させます。

[図8] isinstance 汚染ケース 1
[図8] 理解を助けるために、isinstance(delta, _DeltaRequest)、delta、_DeltaRequest（タイプ）の結果を出力しています。最初のリクエストは設定のためのリクエストで、変調を設定中であるため正常であり、次のリクエストでは _DeltaRequest タイプが str に汚染されて条件をバイパスしています。フロー上、次のターゲットである _process_requests の例を見てみましょう。

[図9] isinstance 汚染ケース 2
[図9] を見てわかるように、上記と同様の内容で、_process_requests は右側のクライアント POC コードの設定により、isinstance(request, _APIRequest) の検査を汚染された設定で通過しました。この汚染は、str に対して OrderSet インスタンスの isinstance 呼び出しが真を返すケースです。これまでに 2 種類の isinstance 汚染を見てきましたが、以降の状況では、汚染を通じて属性を呼び出せるように設定を製作します。

[図10] isinstance 汚染ケース 3
[図10] の isinstance バイパス、関数設定が終わり、[図10] の「内部状態固定」（_INTERNAL_STATE_VARS: () を空にしておく）を設定して、[図11] で内部設定状態を検査できないようにします。

[図11_1] /lightning/app/core/flow.py の _INTERNAL_STATE_VARS チェック関数

[図11_2] /lightning/app/core/flow.py の __setattr__

[図11] を最後に、全体の汚染および設定は終了しました。

[図12] RCE コマンド

[図13] RCE レスポンス

最終的に [図13] で root 権限の exec を呼び出して、[図12] のコマンドを実行して完了します。

2) DeepDiff に対する Delta 汚染を用いた攻撃の簡略な例（左: lightning App サーバー、右: Client）

画像説明

03. 対応策

これまで、lightning 環境でオブジェクト逆直列化（CVE-2024-5452）による RCE 脆弱性が実行される流れを確認してきました。サーバー自体が乗っ取られる攻撃手法であるため、対応策が重要です。そのために、最新バージョンへのアップデートを提案します。

lightning のアップデート
lightning <= 2.2.1 の場合は、lightning > 2.3.3 以上のバージョンにアップデートしてください。
lightning ライブラリの簡易修正
この対応策は、やむを得ないケースに簡易的に防ぐ方法ですので、参考程度にしてください。/api/v1/delta エンドポイントへの簡易なロジック追加（パス /lightning/app/core/api）または、上部のセッション検査部分の強化
IPS による検知および遮断
攻撃は Postman を介して json に dunder 属性を明示してテストします。