Docker 容器逃逸案例分析
摘要： ## 0. 前言 本文参考自《Docker 容器与容器云》 这个容器逃逸的 case 存在于 Docker 1.0 之前的绝大多数版本。 目前使用 Docker 1.0 之前版本的环境几乎不存在了，这篇分析的主要目的是为了加深系统安全方面的学习。 本案例所分析的 PoC 源码地址：[shocker.c](https://github.com/gabrtv/shocker/b
0. 前言
本文参考自《Docker 容器与容器云》
这个容器逃逸的 case 存在于 Docker 1.0 之前的绝大多数版本。
目前使用 Docker 1.0 之前版本的环境几乎不存在了，这篇分析的主要目的是为了加深系统安全方面的学习。
本案例所分析的 PoC 源码地址：shocker.c
1. 预备知识
1.1 Linux Capability
尝试用较为简单的话来说明 Linux 中 Capability 的概念。
为了解决在某些场景下，普通用户需要部分 root 权限来完成工作的问题。Linux 支持将部分 root 的特权操作权限细分成具体的 Capability，如果将某个 Capability 分配给某一个可执行文件或者是进程，即使不是 root 用户，也可以执行该Capability 对应的特权操作。
1.2 Unix 系统文件操作原理
1.2.1 proc 与 user 结构体
以 UNIX V6 为基础进行说明，目前主流的 Linux 版本文件系统的实现原理与 UNIX V6 差别不大。
Unix 系统中与某一个进程密切相关的有两个结构体，它们是 proc 结构体和 user 结构体。
proc 结构体中保存了进程状态、执行优先级等经常需要被内核访问的信息，因此由 proc 结构体构成的数据 proc[] 是常驻内存的。
/*
* Filename: proc.h
*/
struct proc {
// 进程当前状态
char p_stat;
// 标识变量
char p_flag;
// 执行优先级
char p_pri;
// 接收到的信号
char p_sig;
// UID
char p_uid;
// 在内存或交换空间中存在的时间，单位秒
char p_time;
// 占用 CPU 的累积时间，单位时钟 tick 数
char p_cpu;
// 用于修正执行优先级的补正系数，默认 0
char p_nice;
// 正在操作进程的终端
int p_ttyp;
// PID
int p_pid;
// 父进程 PID
int p_ppid;
// 数据段的物理地址
int p_addr;
// 数据段长度
int p_size;
// 进程进入休眠的原因
int p_wchan;
// 使用的代码段
int *p_textp;
}
user 结构体中保存了进程打开的文件等信息，由于内核只需要使用当前执行进程的 user 结构体，所以当某一个进程被移至交换空间时， user 结构体也相应地会被移出内存。
proc 结构体中的 p_addr 指向的数据段，其起始部分的内容即为 user 结构体。
由于 user 结构体内容较多就不列出了，其中一个与文件描述符相关的属性是 u_ofile[]，会在后面提到。
1.2.2 文件描述符
文件描述符是内核为了管理已被打开的文件所创建的索引，是一个非负的整数。
文件描述符保存在进程对应 user 结构体的 u_ofile[] 字段中。
通过文件描述符对文件进行操作涉及到三个关键的数据结构，原理如下图所示：
说明1：
当一个进程启动时，文件描述符 0 表示 stdin，1 表示 stdout，2 表示 stderr，若进程再打开其它文件，那么这个文件的文件描述符会是 3，依次递增。
说明2:
当两个进程打开了同一个文件时（即为图中所示情况），对应到 file[] 中是两个不同的 file 结构体，**因此各自拥有独立的文件偏移量**，不过指向的是同一个 inode 节点，所以修改的是同一个文件。
说明3:
存在以下几种情况（未必是所有情况，也许存在没有列出的其它情况）会导致两个进程的文件描述符指向同一个 file 结构：
-
父进程 fork 出了子进程。此时父进程与子进程各自的每一个打开文件描述符共享同一个
file结构 -
使用
dup或是dup2函数来复制现有的文件描述符
其中第一种情况就是容器逃逸这个 case 的场景，我们知道 Docker Daemon 进程就是容器进程的父进程，如下图所示：
1.3 open_by_handle_at 函数
函数原型：
int open_by_handle_at(int mount_fd, struct file_handle *handle, int flags);
函数功能：
引自 Linux 手册
The open_by_handle_at() system call opens the file referred to by handle.
The mount_fd argument is a file descriptor for any object (file, directory, etc.) in the mounted filesystem with respect to which handle should be interpreted.
The caller must have the CAP_DAC_READ_SEARCH capability to invoke open_by_handle_at().
译：
open_by_handle_at() 用于打开
file_handle结构体指针所描述的某一个文件mount_fd 参数为
file_handle结构体指针所描述文件所在的文件系统中，任何一个文件或者是目录的文件描述符Linux 手册中特别提到调用
open_by_handle_at函数需要具备CAP_DAC_READ_SEARCH能力
**Docker 1.0 版本对 `Capability` 使用黑名单管理策略，并且没有限制 `CAP_DAC_READ_SEARCH` 能力，因而造成了这个容器逃逸 case**
`file_handle` 结构体说明：
```c
struct file_handle {
unsigned int handle_bytes; // Size of f_handle
int handle_type; // Handle type
unsigned char f_handle[0]; // File identifier
}
前面两个字段都好理解，关键是 f_handle[0] 字段，它一般都会是一个 8 字节的字符串，并且前 4 个字节为该文件的 inodenumber
另外 CVE-2014-3519 这个漏洞也与 open_by_handle_at() 函数相关，有时间我再去研究一下那个 case
3. "shocker.c" Line-by-Line Explanation
分析 shocker.c 所需要的储备知识已经介绍完了。
我在代码中用中文给出了比较详细的说明，下面来看下这段容器逃逸 PoC 代码。
/* shocker: docker PoC VMM-container breakout (C) 2014 Sebastian Krahmer
*
* Demonstrates that any given docker image someone is asking
* you to run in your docker setup can access ANY file on your host,
* e.g. dumping hosts /etc/shadow or other sensitive info, compromising
* security of the host and any other docker VM's on it.
*
* docker using container based VMM: Sebarate pid and net namespace,
* stripped caps and RO bind mounts into container's /. However
* as its only a bind-mount the fs struct from the task is shared
* with the host which allows to open files by file handles
* (open_by_handle_at()). As we thankfully have dac_override and
* dac_read_search we can do this. The handle is usually a 64bit
* string with 32bit inodenumber inside (tested with ext4).
* Inode of / is always 2, so we have a starting point to walk
* the FS path and brute force the remaining 32bit until we find the
* desired file (It's probably easier, depending on the fhandle export
* function used for the FS in question: it could be a parent inode# or
* the inode generation which can be obtained via an ioctl).
* [In practise the remaining 32bit are all 0 :]
*
* tested with docker 0.11 busybox demo image on a 3.11 kernel:
*
* docker run -i busybox sh
*
* seems to run any program inside VMM with UID 0 (some caps stripped); if
* user argument is given, the provided docker image still
* could contain +s binaries, just as demo busybox image does.
*
* PS: You should also seccomp kexec() syscall :)
* PPS: Might affect other container based compartments too
*
* $ cc -Wall -std=c99 -O2 shocker.c -static
*/
#define _GNU_SOURCE
#include 
扫我，和云栖在线交流