Qualys のセキュリティ研究者は、Linux カーネルと systemd システム マネージャーに影響を与える 2021 つの脆弱性の詳細を明らかにしました。 カーネルの脆弱性 (CVE-33909-XNUMX) により、ローカル ユーザーは高度にネストされたディレクトリを操作することで root 権限でコードを実行できます。
研究者らがデフォルト構成の Ubuntu 20.04/20.10/21.04、Debian 11、および Fedora 34 で動作する実用的なエクスプロイトを準備できたという事実によって、この脆弱性の危険性はさらに悪化しています。 他のディストリビューションはテストされていませんが、理論的にはこの問題の影響を受けやすく、攻撃される可能性があることに注意してください。 エクスプロイトの完全なコードは、問題があらゆる場所で解消された後に公開されることが約束されていますが、現時点では機能が限定されたプロトタイプのみが利用可能であり、システムがクラッシュする原因となります。 この問題は 2014 年 3.16 月から存在しており、19 以降のカーネル リリースに影響を与えます。 脆弱性修正はコミュニティと調整され、XNUMX 月 XNUMX 日にカーネルに受け入れられました。 主要なディストリビューションでは、カーネル パッケージ (Debian、Ubuntu、Fedora、RHEL、SUSE、Arch) に対する更新がすでに生成されています。
この脆弱性は、一連のレコードからファイルを作成する seq_file コードで操作を実行する前に、size_t から int への変換の結果をチェックしないことが原因で発生します。 チェックを怠ると、非常にネストされたディレクトリ構造 (パス サイズが 1 GB を超える) を作成、マウント、削除するときに、バッファーへの範囲外の書き込みが発生する可能性があります。 その結果、攻撃者は、割り当てられたバッファの直前の領域を指す、「-10 GB - 2 バイト」のオフセットに書き込まれる 10 バイトの文字列「//deleted」を取得できます。
準備されたエクスプロイトを実行するには、5 GB のメモリと 1 万の空き i ノードが必要です。 このエクスプロイトは、mkdir() を呼び出して約 1 万のサブディレクトリの階層を作成し、ファイル パス サイズが XNUMX GB を超えるようにすることで機能します。 このディレクトリは、bind-mount を介して別のユーザー名前空間にマウントされ、その後、rmdir() 関数が実行されて削除されます。 並行して、小さな eBPF プログラムをロードするスレッドが作成されます。このスレッドは、eBPF 疑似コードのチェック後、JIT コンパイル前の段階でブロックされます。
非特権ユーザー ID 名前空間では、ファイル /proc/self/mountinfo が開かれ、バインド マウントされたディレクトリの長いパス名が読み取られ、その結果、バッファの開始前に文字列 "//deleted" が領域に書き込まれます。 行を書き込む位置は、テスト済みだがまだコンパイルされていない eBPF プログラム内の命令を上書きするように選択されます。
次に、eBPF プログラム レベルでは、btf 構造と map_push_elem 構造の操作を通じて、制御されていないバッファ外書き込みが、他のカーネル構造への読み取りおよび書き込みの制御された機能に変換されます。 その結果、このエクスプロイトはカーネル メモリ内の modprobe_path[] バッファの場所を特定し、その中の「/sbin/modprobe」パスを上書きします。これにより、次のような問題が発生した場合に root 権限で実行可能ファイルの起動を開始できるようになります。 request_module() 呼び出し。これは、たとえばネットリンクソケットの作成時に実行されます。
研究者は、特定のエクスプロイトに対してのみ有効であるが、問題自体を解決するものではないいくつかの回避策を提供しています。 別のユーザー ID 名前空間でディレクトリのマウントを無効にするには、「/proc/sys/kernel/unprivileged_userns_clone」を 0 に設定し、カーネルへの eBPF プログラムのロードを無効にするには、「/proc/sys/kernel/unprivileged_bpf_disabled」を 1 に設定することをお勧めします。
注目に値するのは、大規模なディレクトリをマウントするためにバインドマウンドの代わりに FUSE メカニズムを使用する別の攻撃を分析中に、systemd システム マネージャーに影響を及ぼす別の脆弱性 (CVE-2021-33910) を研究者が発見したことです。 FUSE 経由でパス サイズが 8 MB を超えるディレクトリをマウントしようとすると、制御初期化プロセス (PID1) がスタック メモリを使い果たし、クラッシュし、システムが「パニック」状態になることが判明しました。
問題は、systemd が /proc/self/mountinfo の内容を追跡および解析し、unit_name_path_escape() 関数で各マウント ポイントを処理することです。この関数は、データを動的に割り当てられたメモリではなくスタックに配置する strdupa() 操作を実行します。 。 最大スタック サイズは RLIMIT_STACK によって制限されるため、マウント ポイントへのパスが大きすぎると、PID1 プロセスがクラッシュしてシステムが停止します。 攻撃の場合は、最も単純な FUSE モジュールと、パス サイズが 8 MB を超える高度にネストされたディレクトリをマウント ポイントとして使用することを組み合わせて使用できます。
この問題は systemd 220 (2015 年 248 月) から発生しており、すでにメインの systemd リポジトリとディストリビューション (Debian、Ubuntu、Fedora、RHEL、SUSE、Arch) で修正されています。 特に、systemd リリース 2018 では、systemd コードのバグにより /proc/self/mountinfo の処理が失敗するため、エクスプロイトは機能しません。 また興味深いのは、2018 年にも同様の状況が発生し、Linux カーネルの CVE-14634-XNUMX 脆弱性のエクスプロイトを作成しようとしたときに、Qualys の研究者が systemd の XNUMX つの重大な脆弱性に遭遇したことです。
出所： オープンネット.ru