QIANQIANZHUANG Telegram 26
公开一个针对 KernelSU 的侧信道攻击方案,可用于检测(已于 0.8.0+ 中修复,建议尽快更新内核;侧信道攻击的定义请自行阅读维基百科)。

先来梳理 KernelSU 的核心工作流程。KernelSU 通过 kprobe(或在编译时安插 hook)劫持 prctl 系统调用,用户侧主动调用 option0xdeadbeefprctl 与内核交互,内核根据用户侧的指令控制进程行为。KernelSU 最主要的功能(如管理器鉴权、提权 rootunmount 等)都是这样实现的,具体的逻辑参见 ksu_handle_prctl 函数。[1]

需要注意的是,prctl 是一个很常见的系统调用,所有应用都可以主动调用它,而正常的内核是不会有 0xdeadbeef 这个 option 的。这并不会导致函数返回值差异,但相比正常设备,在处理这个的 prctl 时,内核搭载 KernelSU 的设备要多执行一段代码,换句话说,会更慢。这给时间侧信道攻击带来了可乘之机。

早在去年 3 月,就有人发现可以通过分别多次调用 option0xdeadbeef0xdead0000(这个 option 显然不存在,因此内核会直接返回错误,时间很快)的不同 prctl,比较指令执行时间来判断 KernelSU 是否存在[2] 。拜某检测器所赐,这个问题很快得到了修复[3],调查结果是一行日志拖慢了执行速度(见 147 行),注释掉即可。此外,这个修复对管理器或 root 进程才有权执行的请求,还进行了提前鉴权,以便进一步降低执行时间。

查看代码发现,ksu_handle_prctl 中要处理的大多数请求比较简单,很难导致有统计意义的时间差异。但不知为何,上面的修复并没有处理 CMD_BECOME_MANAGER 这个最复杂的请求路径。这个参数用于确定并鉴权 KernelSU 管理器,包括路径检查、权限检查、签名检查等多个步骤,会不会隐藏着攻击点呢?

答案是肯定的。上个月,有人报告 Payback、Vietbank 等应用可检测到搭载了 KernelSU 的内核[4]。使用 stackplz 截获系统调用后,发现 CMD_GET_VERSIONCMD_BECOME_MANAGER 分别被调用了两千次:

[1619|1619|.client.android] prctl(option=-559038737, arg2=2, arg3=549737147384, arg4=4095, arg5=0, ret=-22)
[1619|1619|.client.android] prctl(option=-559038737, arg2=1, arg3=8, arg4=531642947800, arg5=0, ret=-22)


CMD_GET_VERSION 分支在一开始就会做权限检查,执行很快。CMD_BECOME_MANAGER 首先要从用户空间复制内存,还要做路径检查、签名验证,肯定会慢一些,但会慢得这么明显吗?继续研究,我们发现,相比使用 gettimeofday 等微秒级精度的 syscall 获取时间,这两款应用调用了 armv8 处理器搭载的 arch_timer 硬件,通过读取 CNTVCT_EL0CNTFRQ_EL0 两个寄存器达到精确计时。目前主流骁龙处理器的计时器频率是 19.2 MHz,精度可以达到 5 纳秒左右。[5]

修复也很简单:当操作失败一次之后,直接拉黑对应的 uid,不允许下次调用[6]。这样即使慢,也只有第一次会慢,在统计上没有任何意义,不能用于生产环境检测。其实 weishu 自己也提出了更好的修复方式:要么开机时主动扫描应用,由内核确定管理器;要么抛弃管理器,使用 webui。至于还有没有其他的攻击方式,各位可以自行探索。例如去年 Mufanc 提出的方案[7],使用 mincore 检查缺页异常是否触发,从而判断内存是否有异常访问(这个检测方式也常用于游戏外挂检测)。

[1] https://github.com/tiann/KernelSU/blob/dbe43b15407950f268a29b094525bb0cca734d31/kernel/core_hook.c#L202
[2] https://github.com/tiann/KernelSU/issues/300
[3] https://github.com/tiann/KernelSU/commit/814d65cc28331da6e3518b3df65952eff5ed4be7
[4] https://github.com/tiann/KernelSU/issues/1328
[5] https://www.kernel.org/doc/Documentation/devicetree/bindings/arm/arch_timer.txt
[6] https://github.com/tiann/KernelSU/commit/07e475c5dc80b888c059a28fae1c852830bf6bbd
[7] https://github.com/tiann/KernelSU/issues/836



tgoop.com/qianqianzhuang/26
Create:
Last Update:

公开一个针对 KernelSU 的侧信道攻击方案,可用于检测(已于 0.8.0+ 中修复,建议尽快更新内核;侧信道攻击的定义请自行阅读维基百科)。

先来梳理 KernelSU 的核心工作流程。KernelSU 通过 kprobe(或在编译时安插 hook)劫持 prctl 系统调用,用户侧主动调用 option0xdeadbeefprctl 与内核交互,内核根据用户侧的指令控制进程行为。KernelSU 最主要的功能(如管理器鉴权、提权 rootunmount 等)都是这样实现的,具体的逻辑参见 ksu_handle_prctl 函数。[1]

需要注意的是,prctl 是一个很常见的系统调用,所有应用都可以主动调用它,而正常的内核是不会有 0xdeadbeef 这个 option 的。这并不会导致函数返回值差异,但相比正常设备,在处理这个的 prctl 时,内核搭载 KernelSU 的设备要多执行一段代码,换句话说,会更慢。这给时间侧信道攻击带来了可乘之机。

早在去年 3 月,就有人发现可以通过分别多次调用 option0xdeadbeef0xdead0000(这个 option 显然不存在,因此内核会直接返回错误,时间很快)的不同 prctl,比较指令执行时间来判断 KernelSU 是否存在[2] 。拜某检测器所赐,这个问题很快得到了修复[3],调查结果是一行日志拖慢了执行速度(见 147 行),注释掉即可。此外,这个修复对管理器或 root 进程才有权执行的请求,还进行了提前鉴权,以便进一步降低执行时间。

查看代码发现,ksu_handle_prctl 中要处理的大多数请求比较简单,很难导致有统计意义的时间差异。但不知为何,上面的修复并没有处理 CMD_BECOME_MANAGER 这个最复杂的请求路径。这个参数用于确定并鉴权 KernelSU 管理器,包括路径检查、权限检查、签名检查等多个步骤,会不会隐藏着攻击点呢?

答案是肯定的。上个月,有人报告 Payback、Vietbank 等应用可检测到搭载了 KernelSU 的内核[4]。使用 stackplz 截获系统调用后,发现 CMD_GET_VERSIONCMD_BECOME_MANAGER 分别被调用了两千次:

[1619|1619|.client.android] prctl(option=-559038737, arg2=2, arg3=549737147384, arg4=4095, arg5=0, ret=-22)
[1619|1619|.client.android] prctl(option=-559038737, arg2=1, arg3=8, arg4=531642947800, arg5=0, ret=-22)


CMD_GET_VERSION 分支在一开始就会做权限检查,执行很快。CMD_BECOME_MANAGER 首先要从用户空间复制内存,还要做路径检查、签名验证,肯定会慢一些,但会慢得这么明显吗?继续研究,我们发现,相比使用 gettimeofday 等微秒级精度的 syscall 获取时间,这两款应用调用了 armv8 处理器搭载的 arch_timer 硬件,通过读取 CNTVCT_EL0CNTFRQ_EL0 两个寄存器达到精确计时。目前主流骁龙处理器的计时器频率是 19.2 MHz,精度可以达到 5 纳秒左右。[5]

修复也很简单:当操作失败一次之后,直接拉黑对应的 uid,不允许下次调用[6]。这样即使慢,也只有第一次会慢,在统计上没有任何意义,不能用于生产环境检测。其实 weishu 自己也提出了更好的修复方式:要么开机时主动扫描应用,由内核确定管理器;要么抛弃管理器,使用 webui。至于还有没有其他的攻击方式,各位可以自行探索。例如去年 Mufanc 提出的方案[7],使用 mincore 检查缺页异常是否触发,从而判断内存是否有异常访问(这个检测方式也常用于游戏外挂检测)。

[1] https://github.com/tiann/KernelSU/blob/dbe43b15407950f268a29b094525bb0cca734d31/kernel/core_hook.c#L202
[2] https://github.com/tiann/KernelSU/issues/300
[3] https://github.com/tiann/KernelSU/commit/814d65cc28331da6e3518b3df65952eff5ed4be7
[4] https://github.com/tiann/KernelSU/issues/1328
[5] https://www.kernel.org/doc/Documentation/devicetree/bindings/arm/arch_timer.txt
[6] https://github.com/tiann/KernelSU/commit/07e475c5dc80b888c059a28fae1c852830bf6bbd
[7] https://github.com/tiann/KernelSU/issues/836

BY 钱庄


Share with your friend now:
tgoop.com/qianqianzhuang/26

View MORE
Open in Telegram


Telegram News

Date: |

The court said the defendant had also incited people to commit public nuisance, with messages calling on them to take part in rallies and demonstrations including at Hong Kong International Airport, to block roads and to paralyse the public transportation system. Various forms of protest promoted on the messaging platform included general strikes, lunchtime protests and silent sit-ins. Telegram message that reads: "Bear Market Screaming Therapy Group. You are only allowed to send screaming voice notes. Everything else = BAN. Text pics, videos, stickers, gif = BAN. Anything other than screaming = BAN. You think you are smart = BAN. But a Telegram statement also said: "Any requests related to political censorship or limiting human rights such as the rights to free speech or assembly are not and will not be considered." The group also hosted discussions on committing arson, Judge Hui said, including setting roadblocks on fire, hurling petrol bombs at police stations and teaching people to make such weapons. The conversation linked to arson went on for two to three months, Hui said. Find your optimal posting schedule and stick to it. The peak posting times include 8 am, 6 pm, and 8 pm on social media. Try to publish serious stuff in the morning and leave less demanding content later in the day.
from us


Telegram 钱庄
FROM American