G.O.S.S.I.P 阅读推荐 2023-12-19 Lost along the Way

今天要为大家推荐的论文是来自刚刚在哥本哈根结束的CCS 2023的Lost along the Way: Understanding and Mitigating Path-Misresolution Threats to Container Isolation，由华中科技大学李志老师投稿。

随着云原生实践愈加成熟，容器逐渐成为运行计算任务的最小隔离单元。诸如CI/CD等场景通常将容器作为代码构建、测试、部署的环境，各类应用场景中复杂的功能需求使宿主机需频繁与容器交互，而此类交互却也为容器中恶意负载提供了新的攻击面，容器与宿主机间文件系统的隔离缺陷就是交互过程中造成容器逃逸的典型原因之一。

自2017年以来，Docker、Podman、Kubernetes等各类工具与容器交互的功能中不断出现可用于容器逃逸的漏洞，此类漏洞源于容器工具对容器中文件路径的解析越界。具体而言，当容器工具以宿主机进程的身份访问容器中被精心设计的符号链接（symlink）时，相应的文件路径解析过程会被symlink误导，使原本对容器中文件的访问转化为对容器外文件的访问。如图1所示，当使用‘docker cp’将文件从容器中复制给容器所有者时，上述漏洞将导致宿主机中重要文件被容器所有者获得，造成信息泄露与容器逃逸。此类漏洞的评级多为高风险，本工作首次对此类漏洞及相关容器隔离技术的缺陷进行了系统性研究。

图1 路径解析漏洞示例

针对上述漏洞，各容器工具的社区付出了大量的精力进行修复，在交互功能中添加了多种检查以防止将容器中的文件路径越界解析到宿主机中，但同类漏洞仍在不断涌现，甚至出现于已经修复的交互功能中，本工作也从已经过修复的容器工具中发现了多个新漏洞。究其原因，社区虽然能修补容器工具的功能以规避可能出现的路径解析漏洞，但其依赖第三方组件却并未实施相应的检查，且第三方组件的开发人员认为容器社区不应要求他们添加专用于容器场景的安全检查。目前，各容器工具使用了大量第三方组件，即使对现有组件及其供应链进行全面审查也无法保证后续的开发中不会引入相似的问题，而重写所需用到的第三方组件则是不切实际的，也有悖于 “不重复造轮子”的原则。因此，本工作认为消除此类漏洞的责任不在于各容器工具，而应通过增强内核中容器与宿主机间文件系统的隔离来彻底消除。 

基于对漏洞原理的剖析与理解，漏洞的核心成因在于内核层面无法区分某一文件对象是否属于容器，即内核虚拟文件系统（VFS）中属于容器和宿主机的dentry和inode等对象并未被隔离，因此内核并不知道位于容器中的symlink存在解析范围的限制，而当容器中进程突破现有文件系统视图隔离后，内核也不会阻止其访问宿主机中可见的文件。针对此问题，本工作设计并重构了Linux内核对于容器文件系统的隔离机制。该隔离机制本质上是基于安全域的访问控制，其中安全域为容器（低安全域）与宿主机（高安全域）的划分，而访问控制策略则为（1）禁止安全域中文件对象的解析结果高于其安全域；（2）禁止低安全域的文件对象在高安全域中执行。

为实现上述隔离，需首先在VFS层面对容器与宿主机中文件对象进行标识以划分安全域，该标识分为静态与动态两个阶段。其中，静态标识实施于容器的启动阶段，以初步标识内核中属于容器和宿主机的文件对象。但静态标识并不足以作为访问控制的基础，当宿主机中进程因被容器中symlink诱导而访问宿主机上文件时，就结果而言是宿主机中进程将访问宿主机上文件，因而访问控制并不会生效，但实质上却是途经低安全域的路径解析行为发生了越界。针对此类情况，动态标识需在内核文件路径解析的过程中实施，以动态记录路径解析过程途径的安全域。而访问控制策略则是在内核解析文件路径的逻辑最后阶段实施，以确保内核中所有的路径解析行为均会被覆盖，并能阻止所有违反访问控制策略的文件访问。

本工作使用形式化证明的方式从理论上证明了该隔离机制的有效性与安全性，并通过安全评估实验证明该隔离机制可有效阻断所有路径误解析漏洞。同时，性能评估实验表明，该隔离机制对文件系统相关操作所产生的平均开销小于2%，其远远小于现有漏洞补丁带来的性能开销，而且并不影响主流容器工具的兼容性，具有较强的实用性。

原文链接：https://dl.acm.org/doi/10.1145/3576915.3623154

作者介绍：

李志，华中科技大学助理研究员，主要研究方向包括云原生安全、容器安全、云黑产。

原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2023-12-19 Lost along the Way