写在前面
提到内核栈溢出的漏洞缓解,许多朋友首先想到的是栈内金丝雀(Stack Canary)。今天向大家介绍一项在近年,于Android设备中新增,且默默生效的安全机制——影子调用栈:SCS(Shadow Call Stack)。
功能介绍
在通常的函数调用中,被调用函数的返回地址存储在栈上,攻击者可以通过篡改栈上返回地址劫持程序的执行流,常见的攻击方式如通过溢出覆盖返回地址、ROP(Return Oriented Programming)攻击等。
SCS是一项基于LLVM(Low Level Virtual Machine)的安全功能,它通过在函数调用时使用一种安全栈帧来解决这个问题。SCS开启后,这个安全栈帧上存储了函数调用的返回地址,而不是直接存储在常规栈上。函数在使用返回地址时,将直接从安全栈帧中读取。从而避免了传统的、针对栈上返回地址的攻击方法。
Google要求
自Android R开始,AOSP(Android Open Source Project)的CDD(Compatibility Definition Document)要求中,就已强烈建议使能CFI, SCS, IntSan。而在kernel 5.4的版本AOSP的kernel版本默认开启。
依赖条件
SCS需要硬件支持,目前只在特定处理器架构上受到支持,如x86_64架构中的Intel CET或aarch64架构中的Pointer Authentication。这些硬件提供了必要的指令和功能来支持SCS的运行。
SCS目前仅支持aarch64架构,有数据表明在X86_64架构上具有严重性能和安全缺陷,LLVM 在9.0中已将其删除。
开启方法
根据Google介绍,可以为整个内核或者单独为某个用户空间的进程、服务开启SCS,开启方法请参考:
或在编译时将-fsanitize=shadow-call-stack 标志传递给链接命令行。如果当前代码不需要应用SCS,可以使用__attribute__((no_sanitize("shadow-call-stack")))对函数声明。
资料直通车:Linux内核源码技术学习路线+视频教程内核源码
学习直通车:Linux内核源码内存调优文件系统进程管理设备驱动/网络协议栈
安全原理
SCS旨在补充 -fstack-protector,以构建安全纵深防御的目标,防止非线性溢出等任意攻击栈上返回地址的手段。
在 Aarch64 架构上,SCS使用 X18 寄存器来引用影子调用栈,这意味着不必再将 SCS的引用存储在内存中。以此避免将影子调用堆栈的地址暴露给可以读取任意内存的攻击者。SCS不需要错误处理,因为它无条件地信任、使用影子堆栈里的返回地址。
以下面这段demo为例:
Int foo () { Return bar()+1;} |
Demo转换成汇编:
push %raxcallq baradd $0x1,%eaxpop %rcxRetq |
当这段代码在开启SCS后,汇编代码变化为:
str x30, [x18], #8 stp x29, x30, [sp, #-16]!mov x29, spbl baradd w0, w0, #1ldp x29, x30, [sp], #16ldr x30, [x18, #-8]!Ret |
在Aarch64架构上通用寄存器如下,X18目前被大多数ARM预置且未使用。而X30是LR,用于存放函数返回值。
上述代码框中标红指令就是SCS的核心逻辑,分段解释:
str x30, [x18], #8
首先将寄存器 X30 中的数据存储到 X18 指向的内存地址处,然后将 X18 中的地址值增加 8 字节。
ldr x30, [x18, #-8]!
将 X18 寄存器中存储的地址值减去 8 字节,然后将存储在该地址处的数据加载到 X30 寄存器中,同时更新 X18 的值。
功能风险
SCS需要使用Aarch64的X18寄存器来存储影子调用栈的地址,需要默认该寄存器不会用于任何其他目的。虽然当前所有系统库都编译为预留 X18 寄存器,但如果存在第三方库、早期库时,需要确定第三方应用没有使用X18寄存器。
并且OPPO在2020年已率先同Qualcomm和MediTeK两大芯片厂商沟通,率先开通SCS,能有效缓解劫持函数返回地址的危害,无兼容性,功能性上的风险。
功能结果
在OPPO FIND X3项目上,使用IDA逆向bootimage,检测任意内核地址的返回值,确认具备SCS的明显特征,如下截图。
需要注意的是,虽然SCS是一种有效提升设备安全性的漏洞缓解技术,但并不能防御所有的攻击。因此,在Android开发时,还应该采取其他安全措施,如输入验证、内存安全编程、权限管理等来全面保护应用程序的安全性。
原文作者:OPPO安珀实验室