From System Services Freezing to System Server Shutdown in Android: All You Need ....阅读报告

From System Services Freezing to System Server Shutdown in Android: All You Need Is a Loop in an App 阅读笔记

概述

这篇文章从安卓系统进程SystemServer（SS)出发，分析了SS可能面临的DoS攻击。他们将这种攻击称作ASV——安卓中风漏洞。文章前半部分介绍系统背景知识和作者设计的ASV-HUNTER工具，为了理解方便，先跳过这两部分，从后面的几个攻击实例写起。

0. 关键词

一些新的关键词的概念写在前面。

SystemServer

来自：https://www.cnblogs.com/sjjg/p/4821161.html

ZygoteInit分裂产生的SS,其实就是为了调用com.android.server.SystemServer(SystemServer.java)的main函数:其中主要调用init1,init2函数。

• init1()是native函数,启动了 c++运行时库,如：sqllite,OpenGL ES等,然后把调用线程加入Binder通信中。
• init2在Java层,就是单独创建一个线程,用以启动系统各项服务,如：ActivityManagerService,PowerManagerService,BatteryService,WindowManagerService…这些服务都是线程,在SystemServer进程中。

AMS

前面所说的由SS在init2启动的线程之一，AMS是Android中最核心的服务，主要负责系统中四大组件的启动、切换、调度及应用进程的管理和调度等工作，其职责与操作系统中的进程管理和调度模块相类似，因此它在Android中非常重要。

PMS

前面所说的由SS在init2启动的线程之一，包管理服务。

1. 攻击实例

这些实例在https://sites.google.com/site/heartstrokevulnerability/这个网址有视频demo。

1.1 阻碍关键应用修补

PMS在执行add-update的过程中有3个顺序子任务：删除旧包、添加新包和配置新app，它需要获取AMS的锁三次，用来发送三个广播意图到其他组件。

通过触发AMS的ASV#1或ASV#2可以阻止添加和配置包的子任务，方式是在package_removed操作中注册一个接收器。（qs：#1,#2是人为编的号吗？）

效果

当上述AMS的monitor锁（AMS的并发机制类似管程，后面会再提到）被持有超过1分钟时，系统就会重新启动。

Android的PMS有一个故障恢复机制，会回滚未完成的应用。然而它却没有修补脆弱的应用。（qs：为什么？）

1.2 反卸载

移除一个APP包括两个子任务：杀死相关活动进程，并通过ActivityManager注销其运行状态； 然后执行包移除。

在第一步中为了清理应用程序动态记录，需要调用ASV#2中的risky方法AMS.cleanUpApplicationRecordLocked()，所以如果在此注册一定数量的接收器，第一个过程将永远被阻塞，所以无法被卸载。

作者设置的PoC注册了150个接收器，在第一个任务阻塞超过1分钟，最终导致SS的看门狗咬合（watchdog bite），然后软重新启动（在第二部分再详写一下）。

当系统重新启动时，PoC应用监听系统启动的广播，并再次使用ASV#2。

1.3 重复DoS攻击

作者认为ASV可以用来构建RansomWare攻击，什么是RansomWare？简言之就是让你的设备拒绝系统服务（DoS，denial of service，同时向你勒索赎金。知乎上的例子：病毒名叫 GANDCRAB，2018年年初出现的，老爸中招的是 V5.1 版变种，更新于2018年12月份。该病毒在每一个被感染的目录中都留了一个 RODGZ-DECRYPT.txt 文件。

大意就是你的电脑文件已经被加密了，按照他的要求去暗网支付赎金换取解密。From：https://zhuanlan.zhihu.com/p/65385310?utm_source=wechat_session

设计

作者设计了两个PoC，一共用来导致系统不停的soft reboot，一个用来使用ASV冻结设备（qs：冻结设备1分钟不是就会软重启吗？）。Ransomwriter可以在每次冻结之前添加一个view用来告诉用户支付赎金，如果支付过赎金，可以远程控制停止攻击。整个过程不允许用户与屏幕交互。

1.4 通过html-5代码注入进行远程攻击

这部分文中介绍的比较粗略。应用程序的大多数插件可以检索上下文对象，因此注入的恶意代码可以直接调用android API。

例如,下面的代码可以通过Cordova这个插件来发送一个intent广播。

((CordovaActivity)this.cordova.getActivity()).sendBroadcast(intent)

qs： 上面这个是js代码？怎么远程注入进去的？通过插件吗？

2. 攻击实例中的核心概念

这部分补充一些第一部分中提到的关键词，作为第0部分的补充。

看门狗

用于保护系统服务中关键部分（80%）的主锁由 SS 中的一个单独线程监视，称为看门狗（watchdog）。

看门狗作为一个线程在SS中启动，当一个受看门狗监控的服务被启动时，watchdog将会创建一个HeartbeatHandler实例用来主动监控此服务。方法是：周期性的请求monitor锁，如果一段时间都无法获得这个锁，就可以认为在这个锁上的系统服务饥饿或死锁了。

然而当出现超时情况时，看门狗的做法并非杀死相关的服务线程，而是杀死整个SS，并迫使用户空间重新启动。

这种设计可能可能导致一个后果：app可能会控制整个SS上的看门狗咬合（qs：为什么起这个名字？）作者正是将这种攻击命名为ASV,用来类比中风——后者将阻止血液流动。

3. 安卓系统初探

攻击实例看完之后，感觉几个攻击的关键都在于通过持有系统关键服务的锁，使得系统冻结直到进入重启状态，这就需要了解两方面的问题了：

• 安卓系统调用的机制
• 安卓访问关键区的并发控制机制

带着这两个问题再去读读文章前面写的相对“晦涩”的内容吧。

组件通信&系统调用

• 不同组件之间通过intent的方式进行IPC（interprocess communication）；
• app通过Binder机制，可以进行RPC（remote procedure call），从而访问系统服务提供的api，类似操作系统中的系统调用。
• SS进程持有一个binder线程池，用来同步的处理多个RPC（“ the SS process maintains a binder thread pool to handle multiple RPC-based requests simultaneously”）（qs： 这里同步指什么？~好像有点懂了）

看看图

binder机制

安卓系统框架

Android系统分成三层。最上层是application应用层，第二层是Framework层，第三层是native层。

图片来自https://blog.csdn.net/u013309870/article/details/105328743

我的理解&问题

图片出处的作者这么描述：拿Activity举例从上图可以看出来：Activity是由ActivityManager来控制的，而ActivityManager其实是通过Binder获取ActivityManagerService服务来控制Activity的。并且ActivityManager是Android系统FrameWork层的，和应用中的activity不是同一个进程。

SS以及其中AMS等server都是属于FrameWork层的东西，它们通过调用native层的东西来提供系统服务，直观上类似操作系统内核。

qs： 这么理解对吗？

例子

• 当一个app被打开时调用startActivity（），后者就会通过RPC通知到AMS（ActivityManagerServer），在其中加入这个app的记录。

• 当一个app需要发送一个broadcast时，它的activitymanager（参考上面的图）需要通过请求packagemanager来获得所有静态注册的监听器。（qs：怎么个过程？）

• 由于SS具有大多数运行中app的上下文，安卓部分的权限检测、访问控制也要通过SS；SS通过packagemanager向app授予权限，并通过activitymanager验证权限。

关于binder

作为对上一点的补充，这里了解一些android的binder机制，详见网址https://blog.csdn.net/u013309870/article/details/105328743

• 1、Binder是Android提供的一套进程间通信框架。

• 2、系统服务ActivityManagerService,LocationManagerService等都是在单独进程（process）中的，使用binder和应用进行通信。（这里线程进程指的应该都是java中的概念，而非linux内核中概念——linux不区分进程线程）

所以回忆一下0.SystemServer板块的内容，init1中将native的线程加进binder也不难理解。

系统服务的并发控制

SS通过利用java线程的锁机制,文中叫synchronized block（好像类似管程，有空再仔细看）控制并发，例如：

java.util.concurrent.synchronized(monitorlock){...access/modify(data)...}

这种锁机制有这两个特点：

• 对于一个关键代码块，一次只有一个线程可以进入；
• 一个进入代码块的线程可以看到之前进入同一代码块线程所做的修改。

Lock-Suffifixed Method

文中指出很多访问关键代码块的方法具有类似（Locked）这样的后缀，比如AMS中的processStartTimedOutLocked()只有在获得了锁后才能执行，比如这样：

synchronized(AMS){..processStartTimedOutLocked()..}

qs：为什么写这个？可能和逆向后寻找ASV的攻击点有关吧。

SS问题回顾

前面写了这么多，这一小节主要回顾一下SS机制中存在的问题，这些潜在的问题正是1中PoC的设计出发点。

锁的粒度太粗

每个服务中只有一个主monitor锁用来保护大部分关键区域（critical section ，CS），因此当访问这部分的线程拥挤时，可能会有潜在的DoS攻击。

不受watchdog监控的CS

一小部分CS不受看门狗监控，如果一个线程长期占用，可能别的需要同样CS的线程永远无法进入。

恶意占用——SS_Freezing

无论上面的大部分还是小部分的CS，都存在这样的问题。任何app都可以通过Binder自由的请求访问CS，如果恶意的程序（比如通过循环）反复长期地占用这个锁，其它需要这个CS的app就无法使用。整体上SS表现出不负责任，就叫做SS_freezing。

Single-point-of-failure in the SS——单点故障

在2.看门狗中已经介绍过看门狗是如何对关键system services的状态进行检测的（创建一个HeartbeatHandler，周期性检查critical system service的状态），类似下面这样：

monitor(){synchronized(AMS.this){}}

如果无法获得锁到一定长的时间，就会重启整个SS。因此，app可以通过RPC反复使用某个受看门狗监管的CS，最终会导致watchdog的alert，从而关闭/重启SS，这个过程称为SS_Shutdown。

总结

总体来看，任何app可以不受控制的请求SS中的服务（或CS——关键代码段），大部分服务受看门狗监管。如果恶意app对某个CS反复请求，或者导致其它app长期无法进入，或者在看门狗监管下触发警报，最终导致SS重启。

4. Hunting ASV——捕获ASV的工具

设计思路

先有一个新的概念：无论是SS_Shutdown还是SS_Freezing，设计上都需要触发SS去执行一个使用CS的复杂方法，我们称这些复杂方法为risky methods。

设计上，整个流程先上图：

ASV-Hunter包括以下主要的部分：

• 静态代码分析器：用来获得控制流程图和调用图（ control-flow graphs(CFGs) and call graphs）
• 候选risky methods分析器：用来筛选危险方法
• 触发点分析器：识别触发方法，触发方法需要能够调用相应候选危险方法
• 候选方法测试器：用来测试候选危险方法是不是实质上可以触发，如果是，交给测试人员做进一步测试。

然后分别来看一看每一个部分的工作

静态代码分析器

它首先以系统服务的反编译 Java 字节码文件作为输入，并使用 SOOT分析框架将 Java 字节码指令转换为中介表示(IR)，即 JimpleIR。在 SOOT 的支持下，为每个.class 文件高效地构建了方法级 CFG。

候选risky methods分析器

筛选标准

• 该方法包含更复杂的结构（循环）
• 该方法包含的同步块中包含更多的指令
• 该方法调用更多的其他方法
• 该方法更经常的被别的方法调用
• 该方法是前面提到的lock-suffixed方法
• 如果在持有看门狗监管下的锁时调用该方法

上面标准的前四条衡量了这个方法的复杂性，和SS_Freezing有关；后两条是布尔值，和SS_Freezing和SS_Shutdown有关。

举个例子，文中作者第一轮用这样的标准筛选：[(δ > 1) ∧ (γ > 40) ∧ (σ > 3) ∧ (e > 3) ∧ true ∧ true],析取范式的6个部分分别对应上面的6个标准。它匹配和返回的标准：包含至少 2 个循环，在关键部分中有 40 多个指令，至少包含4 个调用节点，在调用中至少出现 4 次，是一个锁定的后缀方法，并由看门狗线程检查的监视器锁来保护。

根据最终得到的171个危险方法，找到了两个ASV。

触发点分析器

触发点是第三方应用程序的方法，它可以触发执行相应候选风险方法。触发点分析器在调用图上进行backward reachability analysis——反向可达性分析。一些具体的过程这里先不写了。

候选Risky方法测试器

通过 AndroidBinderIPC 机制调用SS中的服务，并使用特定的调用ID作为参数，这样容易将调用的risky方法和调用过程形成对应。

hunting结果

通过上面的过程找到了一些脆弱的服务易于收到攻击，这里简单举一个例子：AMS中的 risky method——broadcastIntentLock()

• 这个方法是用来处理广播的接收者并将广播信息传递给他们，它被广泛使用。
• 同时这个方法是ActivityMenager中的一个Lock-Suffixed方法，也就是说，仅当获得持有AMS.this这个锁时，才能执行它；且这个锁是在看门狗的监管下的（有造成SS_Shutdown的潜力）。
• 同时，通过对调用图的分析，这个方法实质上复杂度是较高的，有几个嵌套循环。

为了利用这个方法，作者的团队注册了大量的广播接收器，之后通过一个触发点调用风险方法（例如sendbroadcast（）），导致了SS的freezing乃至shutdown。

5. 可能的防范措施

作者还简单列举了一系列潜在的防范方法。主要是一些概念性的东西，这里先不写了。

6. 总结

这篇文章分析了一种针对安卓系统服务潜在的攻击方式ASV，攻击的出发点是安卓SystemService（SS）和看门狗机制和并发控制在设计上的一些问题：

任何app可以不受控制的请求SS中的服务（或CS——关键代码段），大部分服务受看门狗监管。如果恶意app对某个CS反复请求，或者导致其它app长期无法进入，或者在看门狗监管下触发警报，最终导致SS重启。

所以可以通过一个简单的逻辑进行攻击：（通过循环）反复请求系统服务——正如文章题目所言。

为了找到脆弱的系统服务，设计了ASV-Hunter和一套评判标准，用来高效自动地寻找攻击目标（risky method）。