Towards Understanding and Defeating Abstract Resource Attacks for Container Platforms¶

Author: Wenbo Shen, Yifei Wu, Yutian Yang, Qirui Liu, Nanzi Yang, Jinku Li, Kangjie Lu, Jianfeng Ma

1 现有的抽象资源限制技术 ¶

1.1 Kernel Layer¶

1.1.1 rlimit¶

rlimit 是 Linux v2.4 引入的资源限制机制，针对特有的 16 种资源类型，进行用户 / 进程级别的资源限制，例如RLIMIT_NOFILE限制每个进程打开的文件数量。

缺点：可限制的资源类型固定；只能实现进程 / 用户级别的限制，而容器通常包含进程树和多个处于同一 user namespace 下的用户。

1.1.2 sysctl¶

sysctl 是 Linux 用于配置 Kernel 参数的接口，可以通过配置六种资源类型的参数来在系统级别限制抽象资源的使用，例如fs配置文件系统限制，vm配置虚拟内存限制等。

缺点：只能对整个系统使用的资源总量进行限制，反而有助于抽象资源攻击。

1.1.3 namespace 和 cgroups ¶

Linux 内核提供的隔离机制，但只能对固定类别的抽象资源进行限制，难以扩展到其他资源类型。

1.2 Container Layer¶

Sysdig Falco 是运行时容器安全监控工具，主要由 event collector 和 event monitor 两个组件组成，通过 eBPF 和 kprobe 技术实现运行时 hook 调整与灵活的事件监控，基于捕获的事件是否违反用户设定的 Rules 进行相应举措。

缺点：Falco 从设计上来说不适用于抽象资源攻击检测，因为其 hook 点位于 syscall 的入口和出口，不能有效监控内核资源的变化。

1.3 Orchestration Layer¶

Kubernetes namespace 是容器编排层的资源隔离机制，可以将 Kubernetes 对象（e.g., pods, services, etc.）划分到不同的 namespace 中。

Kubernetes 还使用 limit ranges（基于 cgroups）来限制硬件资源的使用。

缺点：Kubernetes 的 namespace 和 limit 都是 cluster 级别的资源隔离限制，且其底层仍是由 Kernel 提供的机制实现，因此无法限制抽象资源攻击。

2 抽象资源攻击示例 ¶

2.1 Attacking idr of PID¶

Linux 内核引入了 struct idr 用于整型 ID 管理，进程管理同样通过idr来分配 PID，alloc_pid函数实现如下：

struct pid *alloc_pid(struct pid_namespace *ns,pid_t *set_tid, size_t set_tid_size)
{
    ...
    nr = idr_alloc_cyclic(&tmp->idr, NULL,pid_min, pid_max, GFP_ATOMIC);
    ...
    if (nr < 0) {
        retval = (nr == -ENOSPC) ? -EAGAIN : nr;
        goto out_free;
    }
    pid->numbers[i].nr = nr;
    ...
}

攻击者可以通过发起大量 fork 请求耗尽idr中的资源，导致其他进程无法分配 PID。

在该攻击中，Linux PID namespace 的隔离本质上是实现了 namespace 内部与 root PID namespace 中 PID 的映射，换句话说，root PID namespace 仍然是被共享的，因此攻击者可以跨 namespace 发起攻击耗尽idr资源

cgroups 机制的确能够限制进程直接 fork 的数量，但是攻击者可以欺骗内核使其产生大量 fork 而绕过限制，例如发起大量网络交互或限制 device 生成 NET 和 Block softrqs（这将导致 kernel 创建大量中断处理线程）。

2.2 Attacking memory dirty ratio¶

Linux 为了提高文件读写速度采用了缓存机制，先在内存中缓存文件修改内容，待 dirty 值较高时 kernel 唤起后台进程异步写入磁盘，当dirty ratio较高时 kernel 会关闭 writeback 机制转为直接写入磁盘，因此可以通过耗尽 dirty memory 来大幅降低系统的文件读写性能。

其他攻击 Todo（看完了但是还没写完）¶

3 检测抽象资源 ¶

内核中有数以万计的变量和数据结构，本文实现分析工具定位发现其中可能的抽象资源对象，架构如下：

先通过共享抽象资源检测发现潜在的抽象资源对象，再通过容器可控性分析以确定这些抽象资源是否可以被容器利用。

3.1 共享抽象资源检测 ¶

3.1.1 Configuration-based Analysis¶

Linux kernel 提供 sysctl 接口来配置系统参数，通过观察我们发现大部分配置都用于限制抽象资源的使用，因此我们可以检测 sysctl 配置项来找出潜在的抽象资源对象，步骤如下：

1. 根据 sysctl 数据类型找到所有 sysctl 相关数据结构
2. sysctl 数据结构通常包含用于展示位于/proc/sys/目录下 sysctl 值的函数，通过分析这些函数，我们可以精确定位这些系统变量
3. 通过 use-def chain 分析变量是否参与 compare 操作（limit 时需要比较）

3.1.2 Access-based Analysis¶

Linux 通常通过 lock 或 atomic 机制保护共享资源，因此我们可以通过分析使用了这些机制的变量以确定抽象资源，如果一个变量在 lock 和 unlock 之间的值进行修改，或使用 atomic 和percpu counter，那么这个变量可能是一个抽象资源对象。

3.2 容器可控性分析 ¶

通过 control-flow 分析，我们能够发现 syscall 路径中可控的抽象资源，如果这些资源没有被 Seccomp、namespace 或 cgroup 限制，该资源即为容器可控。

问题？¶

待了解技术实现细节

1. （Section 5 Table 4）检测抽象资源对象时如何实现统计 Res Type？

评论