从CrowdStrike蓝屏事件展望Linux eBPF安全风险

2024年7月19日，互联网社交媒体上发现大量企业Windows系统主机出现BSOD（Bluescreenof Death）并循环重启。北京天地和兴科技有限公司安全研究人员第一时间参与了蓝屏问题的系统分析，发现造成蓝屏的程序均为csagent.sys，该程序为CrowdStrike终端安全软件组件。

随后经确认，因CrowdStrike Falcon的通道文件291中的一个缺陷更新导致逻辑错误，进而导致 Windows系统崩溃，造成广泛的BSOD事件。全球关键基础设施受到干扰，影响范围广泛，从停飞的航班到停运的公共交通系统均受到不同程度的波及。

该事件不由得引起安全研究人员对于主机（组件）系统安全的思考，Windows尚且如此，那么同样占据巨大市场份额的Linux系统呢？

什么是eBPF？eBPF由BPF发展而来，BPF全称Berkeley Packet Filter（伯克利数据包过滤器），1992年由Steven McCanne和VanJacobson提出，1997年引入Linux Kernel 2.1，3.0中增加了即时编译器，应用在网络过滤领域。2014年Alexei Starovoitov实现了eBPF（扩展伯克利数据包过滤器）并扩展到用户空间，威力更大。常用的TCPDUMP&LIBPCAP就是基于此过滤器。在Linux Kernel 4.x中，扩展了内核态函数、用户态函数、跟踪点、性能事件（perf_events）以及安全控制等事件类型。尤其是近几年云原生快速发展，也带动了eBPF的繁荣。微软、Google、Facebook等企业成立eBPF基金会，Cilium公司也发布了基于eBPF技术实现的网络产品。不过，在eBPF技术带动新业务快速发展的同时，也带来了一系列的安全威胁。

早在DEFCON-29峰会上，安全研究员Pat Hogan分享了关于eBPF被恶意利用的案例：《Warping Reality - creating and countering the next generation of Linux rootkits using eBPF》，他介绍了 eBFP rootkit的应用场景，包括网络（运行）等场景，以及如何检测eBPF被恶意利用等。

相比国外，国内关于eBPF被恶意利用的资料较少，相关技术分享也较少。如果不加以重视，势必影响到国内公司在网络安全防御体系层面的建设，进而导致安全防护落后于国外，给企业生产安全甚至国家安全带来较大的风险。

未知攻，焉知防。要想做好防线，必须要知晓其攻击原理。天地和兴安全研究人员分析eBPF的rootkit的设计原理，首先，eBPF的功能如下：

• 网络

• 观测

• 监控

• 跟踪（性能分析）

• 安全

网络方面，Cilium等云原生公司做了很多网络层的产品，在实现网格管理的同时，也设计出相应的网络层面安全策略，尤其是在网络编排领域。而在观测、监控等领域也有很多产品。尤其是运行时安全（Runtime Security）领域，Datadog、Falco、Google等公司也都推出了相应的产品。

然而eBPF技术的hook点同样是安全的“重灾区”。

从上图中可以看出，eBPF的hook点功能包括以下几部分

• 可以在storage、network等与kernel  mode交互

• 可以在kernel中的功能模块交互

• 可以在kernel mode与user mode交互

• 可以在user mode进程空间交互

eBPF的功能覆盖XDP、TC、Probe、Socket等，每个功能点都能实现kernel mode的篡改行为，从而使得user mode完全致盲，哪怕是基于内核模块的HIDS，一样无法感知到这些行为。

因为eBPF的灵活性和强大性使其成为现代计算环境中的热门工具，但其日益复杂化导致漏洞激增。自 2021年以来，与eBPF相关的CVE已达36个，其中仅在2024年的前七个月就报告了10个，这些漏洞凸显了将eBPF集成到生产环境中所带来的固有风险。

新的威胁——容器逃逸分析

Docker容器逃逸已经是老生常谈的安全话题了，一般使用AppArmor中禁用mount 的方式限制容器逃逸，参见下方代码。

但“道高一尺，魔高一丈”，如果攻击者获取了CAP_DAC_READ_SEARCH 权限而非CAP_SYS_ADMIN 权限，那么就可以使用系统调用来实现逃逸至宿主机的root file system 。Linux从内核4.17版本开始，可以通过perf_event_open 来创建kprobe 和uprobe ，并且tracepoint 子系统新增了一个 raw_tracepoint 类型，该类型可以结合eBPF技术，并通过简单的系统调用实现容器逃逸，这就给了攻击者可乘之机。

eBPF  kprobe、tracepoint使用的条件如下表所示：

Linux内核为eBPF程序提供了一系列固定的函数，这些函数被称为BPF-HELPERS 。常见的helper有bpf_probe_read （安全地从内核空间读取数据）、bpf_probe_write_user （尝试以一种安全的方式向user mode空间写数据）、bpf_override_return  （用于error injection，可以用于修改kprobe监控的函数返回值）。这些helper提供了读写整个机器上任意进程user mode空间的功能，同时提供了内核空间的读取数据功能，当攻击者向内核加载eBPF程序，那么有许多种办法进行权限提升或者容器逃逸，如读取内核空间里的敏感信息，或者hook 关键系统调用的返回点，获取其他进程空间里的敏感信息；修改其他高权限进程里的数据，注入shellcode 或者改变进程关键执行路径从而执行攻击者构造的命令等。

到这里不妨用攻击者的角度思考有什么进程或服务是linux各个发行版最常见，并且可以直接用来执行命令的呢？

熟悉安全和运维的读者应该对cron 不陌生，作为linux计划任务中最常见的服务，可以定时执行任务，甚至可以指定用户，由于需要及时更新配置文件，调用syscall 十分频繁，因而用eBPF技术来hook是攻击者常用的手段。这里安全研究人员针对vixie-cron 作为分析对象， 因为多数linux发行版如 Debian、CentOS都使用vixie-cron 来实现cron进程。

vixie-cron 的整体逻辑比较简单，代码主循环中每次等待一段时间后都会执行任务并加载cron 的配置文件，关键函数为load_database 。

·

SPOOL_DIR 是一个宏，代表了存放crontabs文件的目录，默认为 tabs 。

在Debian中SPOOL_DIR 代表的就是 /var/spool/cron/crontabs 目录。 

获取系统crontab 的信息。

if判断，如果判断通过，则进入处理系统 crontab 的函数。

经过简单分析可知，当使用eBPF程序去获取 stat syscall 返回的时候，如果能够修改返回的 数据，就可以让 vixie-cron 去处理/etc/crontab。结合 bpf() ，如果容器中的应用或服务能够访问 bpf() 系统调用，攻击者可能会利用它加载恶意的eBPF程序。在特定情况下，利用漏洞或配置不 当，可能导致容器逃逸。

天地和兴安全研究人员这里也给出预防容器逃逸的措施供读者参考研究: 

• 最小化容器权限:确保容器运行的用户权限尽可能低，并限制对 bpf() 系统调用的访问。

• 使用seccomp配置:配置seccomp策略，防止容器中的进程调用 bpf() 或其他高风险系统调用。 

• 内核更新:及时更新内核，以修复与eBPF相关的已知漏洞。 

• 限制eBPF功能:使用cgroup和其他限制措施，防止容器化进程滥用eBPF。 

• 监控和审计:持续监控容器内的活动，检测并响应潜在的逃逸尝试。

References

https://access.redhat.com/solutions/7068083

https://www.blackhat.com/us-21/briefings/schedule/#with-friends-like-ebpf-who-needs-enemies-2 3619

https://defcon.org/html/defcon-29/dc-29-speakers.html#path 

https://sysdig.com/blog/the-art-of-writing-ebpf-programs-a-primer/