介绍
这是一篇来自2021CCS的论文，作者有Nanzi Yang, Wenbo Shen, Jinku Li, Yutian Yang, Kangjie Lu, Jietao Xiao, Tianyu Zhou, Chenggang Qin, Wang Yu, Jianfeng Ma, Kui Ren。
概述
本文的贡献如下：
- 新的攻击面：作者揭示了一个影响操作体系主要功能，影响多个操作体系，操作体系虚拟化共有的抽象资源攻击。
- 攻击实用性评估：四大云盘算厂商提供的self-deployed native container环境均受到抽象资源攻击影响。
- 体系化分析：作者设计并实现了一个静态分析工具，并识别出501个可被容器重复触发的抽象资源。
- 作者将工具源码以及效果开源在Github上了
Github地点：https://github.com/ZJU-SEC/AbstractResourceAttack
概述
这篇论文揭示了一种操作体系级虚拟化的固有问题-共享内核变量和数据结构。和物理资源（CPU，内存）相比，这些内核变量和数据结构也被称为抽象资源。基于这些共享抽象资源，该论文提出一种新型攻击 - 抽象资源攻击。通过实验证实，抽象资源攻击可影响操作体系所有主要功能，包罗历程管理、内存管理、存储管理、IO管理，造成体系崩溃大概性能大幅度降落；同时可攻击大多数主流操作体系，包罗Linux，FreeBSD以及Fuchsia内核；同时该论文进一步在四大云厂商环境进行验证，证实抽象资源攻击在其上部署的共享内核容器环境中依然可行，揭示该攻击影响的广泛性和严峻性。该论文实现并开源了一个静态分析工具，体系化分析出Linux中潜在的抽象资源攻击，找出了超过500个Linux内核中易受攻击的抽象资源。
背景
操作体系级虚拟化是云盘算中的一项核心技术，它允许多个独立的和隔离的用户空间环境在同一个内核上运行。目前，操作体系级虚拟化以Linux的container为代表, 比较常用的另有FreeBSD的Jails以及Solaris的Zones.
文章利用容器来代指这些共享内核的独立用户执空间，目前应用最为广泛的容器是Docker container，Red Hat Openshift和Apache Openwhisk这两个常见的云平台都利用了Docker container.
与传统虚拟化为每一虚拟机维护单独的内核差别，容器凭借其共享内核的特性，拥有更快的启动速度已经更好的资源利用服从。在Linux容器中，内核提供了namespace和cgroup机制实现资源隔离和限制，内核还提供了如seccomp和selinux等安全机制进行安全加固。由于容器的广泛应用，其安全问题也备受关注，之前的研究主要会合于信息泄漏，侧信道攻击，带外负载等问题。
抽象资源攻击
与之前的工作差别，本文从一个新颖的角度进行切入，作者认为除了如CPU, memory这些物理资源以外，操作体系中维护的变量和结构体也是非常重要的资源。运行在同一操作体系内核上的容器（native container）可以通过体系调用来访问内核提供的服务，而且体系调用会利用大量内核维护的变量和结构体，因此容器是共享这些变量和结构体的。
基于这种容器和内核之间的复杂数据依靠关系，作者将内核维护的变量和结构体统称为抽象资源（Abstract Resource），并提出了一种新型攻击—抽象资源攻击（Abstract Resource Attack）, 这种攻击的核心是恶意容器通过耗尽内核中容器间共享的抽象资源，发起拒绝服务(DoS)攻击，并且其具有以下特点：
- 可以在non-privileged，drop all capabilities的容器中，在不利用任何内核毛病的环境下发起攻击。
- 攻击能影响操作体系提供的各大主要功能。
- 攻击能影响多个主流操作体系如Linux，FreeBSD和Fuchsia。
- Linux中已有的namespace，cgroup等机制无法对抽象资源进行有用的限制。
以上特点分析抽象资源攻击这一新的攻击面是操作体系级虚拟化引入的共有问题，而且现有机制无法对其进行有用的限制。
抽象资源攻击的root cause
作者起首从一个例子-nr_files攻击来阐述Abstract Resource的root cause.Linux内核存在一个nr_files全局变量，由于namespace,cgroup都没有对nr_files变量进行隔离和限制，恶意容器能轻易耗尽nr_files，使其达到files_stat.max_files上限，从而使被攻击容器无法进行与文件相关的操作。
针对云平台的抽象资源攻击
为了进一步评估抽象资源攻击的影响，作者还挑选了7种抽象资源，在四大云厂商提供的self-deployed native container环境中进行了实验。实验效果表明，各个云厂商的self-deployed native container环境都轻易受到抽象资源攻击的影响。实验过程中，作者还惊喜地发现，Google的安全容器gVisor也受到两种抽象资源攻击（nr_files和netns_ct->count）的影响。这是因为gVisor虽然实现了本身的用户态内核，但是其终极还是会向宿主机内核发起体系调用完成相应的请求。作者已经将相关问题披露给了四大云盘算厂商，并且得到了他们的复兴和确认。
静态分析工具的设计与分析效果
末了，作者还设计并实现了一个LLVM静态分析工具体系化，自动化地找出Linux内核中可被容器耗尽的抽象资源。为了办理如何识别出故意义的抽象资源以及如何区分出抽象资源是否能被容器耗尽两大挑战，该工具分别对应包罗了configurations-based analysis和access-based analysis两大部分。在工具分析出的1010个效果中，此中有700个与驱动无关的资源，310个与驱动相关的资源。经过进一步的动态触发验证，在这700个资源中，有389个资源能被容器重复触发，true positive rate为55.6%。在310个驱动相关资源中，排除此中92个在当地没有对应硬件支持的资源，此中有112个抽象资源可以被容器重复触发，true positive rate为51.4%。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
