嘉宾 | 申文博 整理 | 哪吒

出品 | CSDN云原生

2022年6月7日，在CSDN云原生系列在线峰会第7期“安全技术峰会”上，浙江大学百人计划研究员、博士生导师申文博以内核传统攻击和防护演化为切入，分享了容器给内核安全带来的新挑战——抽象资源攻击和内存计数问题。

据统计，2008-2019年，Linux内核代码量急剧增长，到2019年已超过2300万行，而最新统计数据显示，Linux内核代码量更是将近2800万行。

与此同时，Linux只是Android生态的一部分，在Linux内核之上，还有HAL、Runtime、Framework、Applications等多层。

我们知道，代码量跟Bug数量或者跟漏洞数量成正比，也就是说，代码量越多，Bug数量、漏洞数量也会越大。这些漏洞往往会被攻击者利用，产生新型的攻击。

同时，新型的攻击又催生了新型的防护，所以对操作系统内核的攻防是在不断的对抗中演化升级的，可谓没有绝对安全的系统，也没有绝对强的攻击手段。

内核传统攻击和防护演化

攻防一般围绕着代码注入、代码重用、数据攻击进行对抗。下图展示的是内核攻击和防护的演化历程。

代码注入攻防

通过内核漏洞

• 篡改已有代码text section

• 注入新的代码

• 或者跳到用户代码，比如jump-to-user

系统控制能力大

• 可执行新代码

多见于早期Linux

• 比如Kernel Text RWX（Android 2013）

内核代码注入防护

• 保护已有代码W^X

• 硬件支持，杜绝注入

• 数据不可执行（2001 XN ARM; NX AMD）

• 特权不可执行（2011 SMEP Intel; PXN ARM）

通过内核页表来实现

• 在内核页表设置相应的保护位，实现保护

• 多数Android设备, 包含Google Pixel

• 防御性弱，内核页表被改掉即失效

• 对内核页表没有保护

• 攻击者可篡改页表，去掉保护

• 进而篡改代码   

通过隔离环境保护内核页表

• 通过隔离环境，避免内核漏洞影响

• 实现了纵深防御defense-in-depth

内核代码重用攻击

内核代码重用攻击也被称为控制流劫持攻击，该攻击无法注入新代码，而是重用已有代码。一般通过篡改控制流，拼接已有函数片段，实现攻击函数。

攻击方式有两种：

• Return-oriented programming (ROP) ：通过注入恶意返回地址，构造攻击函数

• Jump-oriented programming (JOP)：通过篡改函数指针，构造攻击函数

内核数据攻击

控制数据被保护后，攻击者提出非控制数据攻击

• 返回地址和函数指针以外的数据

• Data-oriented programming

• 影响关键的安全特性：仅利用非控制数据攻击做到内核提权

非控制数据防护 

• 种类繁杂，难以实行统一有效保护

• 主流操作系统均缺乏对数据攻击的有效防护

总体来说，攻击演化呈现出

• 攻击难度指数级增加

• 复杂性指数级增加

• 隐蔽性在增加

• 控制能力减弱

• 数据攻击依然能root内核

防护演化呈现出

• 软件到硬件

• 学术界原型到产业界实用方案

内核在容器场景下的安全问题

容器是操作系统级虚拟化，它是由同一个内核虚拟出来多个用户空间的实例，每个用户空间的实例，不需要维护单纯的内核。用户空间的实例，也叫容器实例，它不用单独维护内核，所以效率高、启动快，并且配置比较灵活，会被广泛应用于代码。

在容器场景下，安全主要体现在抽象资源攻击、内存计数问题。

抽象资源攻击

容器本质是基于进程的资源隔离，由namespaces负责隔离，当前内核支持8种namespaces，包含UTS、IPC、mount、PID、network、user、time、cgroup；由control groups进行限制，当前内核支持13种cgroups，主要用于限制CPU、内存和设备资源。

容器注重限制物理资源，忽略抽象资源，如内核变量。我们发现，这些抽象资源同样可以被DoS攻击，例如打开大量文件，耗尽nr_files；所有新打开文件操作均会失败，导致无法运行新程序。同时发现，大的云厂商均可受到抽象资源攻击。

因此，内核数据同样决定操作系统功能的可用性，容易导致DoS攻击；内核data dependency复杂，难以彻底解决DoS问题；高安全性要求场景建议使用虚拟机隔离。

内存计数问题

内核依赖memcg对内存进行计数，而memcg未经系统性安全分析，存在安全隐患。因此，针对内存计数问题，我们做了大量的工作。

• 形式化定义了内存计数的步骤

• 分析了policy design的问题

• 设计自动化工具分析implementation问题

• 发现了policy design中导致的计数缺失的问题

• 设计了基于编译器的自动化分析工具，对policy implementation进行系统性分析

截至目前，我们发现了53个计数Bug，已确认其中的34个并提交patch。

总结来说，内核安全性在对抗中大幅提升，但对数据攻击防护依然不足。而容器场景给内核带来了新的机遇，也带来了新的安全挑战，包括抽象资源攻击和内存计数问题。

---

聚焦云原生新技术、新实践，帮助开发者群体赢在开发范式转移的新时代。欢迎关注CSDN云原生微信公众号～