2019年2月，容器runc的逃逸一个漏洞（CVE-2019-5736）让整个容器圈炸了锅。攻击者只要能在容器里执行代码，漏洞就能覆写宿主机上的容器runc二进制文件，直接拿到宿主机的逃逸root权限。这不是漏洞理论推演，是容器实打实的逃逸。

runc是逃逸什么？它是Docker、containerd、漏洞CRI-O这些容器运行时底层的容器那个“执行者”。你敲下docker run，逃逸最终是漏洞runc去调用clone、pivot_root、容器execve这些系统调用，逃逸把容器进程跑起来。漏洞它站在宿主机和容器之间的边界上，一旦它被攻破，边界就没了。

漏洞怎么发生的

问题出在/proc/self/exe上。runc在容器启动时会去读这个符号链接，指向的是runc自己的二进制文件。攻击者可以在容器内把/proc/self/exe指向的文件的文件描述符保持打开，然后等着runc下次执行——比如docker exec进入容器时——趁机往那个fd里写入恶意代码。runc以root身份运行，这个写入操作直接落到了宿主机上的runc二进制文件上。

说白了就是：容器里的进程骗runc打开了自己的可执行文件，然后趁runc不注意把它替换掉了。下次任何人再调用runc，跑的就是攻击者的代码。

这个利用链条需要几个条件配合：容器内进程能以root运行（默认情况）、/proc没有被mask掉、攻击者有办法让runc重新执行。Docker默认配置下这些条件全满足。Aleksa Sarai发现并报告了这个漏洞，PoC很快在GitHub上公开，利用代码不到100行。

修复方式为什么值得说

runc团队的修复方案不是打补丁堵住/proc/self/exe，而是引入了一个叫memfd的机制。简单讲，runc在启动容器之前先把自己复制一份到内存文件描述符里，之后所有需要重新执行自己的操作都从这个内存副本走，不再碰磁盘上的二进制文件。攻击者就算控制了/proc/self/exe，指向的也是一个只存在于内存中的副本，写不进去。

这个修复思路挺聪明。它没有去跟/proc的语义较劲，而是直接改变了runc的自我复制方式。从根上切断了攻击路径。

这事说明了什么

容器的隔离一直是个“够用就好”的故事。namespace和cgroup做的是资源视图隔离，不是安全边界。runc以root跑在宿主机上，它跟容器进程之间的交互面比大多数人想象的要大得多。CVE-2019-5736只是把这个事实摊开了。

我印象比较深的是当时很多团队的应急反应——升级runc需要重启Docker daemon，而重启Docker意味着所有容器全停。生产环境里这个操作的成本极高。有些团队选择先加Seccomp策略挡住/proc/self/exe的写入，算是临时止血。这也暴露了容器安全的一个现实：底层组件的漏洞，修复代价往往不在补丁本身，而在运维层面。

后来runc又出过几个逃逸漏洞，比如CVE-2021-30465的符号链接挂载问题、CVE-2024-21626的文件描述符泄漏。模式都差不多：runc和容器之间的某个交互细节没处理好，被攻击者找到了写入或越权读取的路径。容器安全不是一劳永逸的事，runc作为最底层的那一环，它的攻击面注定会被反复审视。

如果你现在还在跑老版本runc，查一下runc --version。1.0.0-rc6之前的版本都有问题。升级不难，难的是安排好那个重启窗口。

(责任编辑：探索)