介绍
这是一篇来自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%。
