Android内核漏洞严重影响了Android平台的安全。一旦内核被攻破，所有依赖内核完整性的安全机制都岌岌可危（比如加密、进程隔离、支付、指纹验证等）。作为Android平台最后的防线，TrustZone也会受到威胁，因为内核可以从很多被信任的接口向TrustZone发起攻击。因此，理想情况下Android生态圈应该及时消灭内核漏洞。然而从Google的Android Security Bulletin上看，Android内核漏洞的数量呈飞快上涨的趋势（图1所示）。虽然这代表着人们对内核安全的投入逐渐增大，但与此同时这些漏洞一旦公诸于众，在很长一段时间都难以得到修复，导致越来越多的可以公开利用的漏洞变成了黑产手中的利器。纵观近期几起影响全世界的重大恶意malware事件[1-4]，它们都携带了root工具，并且root的方法不是源自公开的PoC，就是直接重用了一些一键root工具的库。

　　人们经常宣称“Android容易被攻击”或者“Android不如苹果安全”。但是，表1列出了几乎同时期iOS和Android内核漏洞数量的比较，不难发现Android漏洞公布的频率甚至不如iOS多。虽然漏洞和漏洞并不能直接拿来比较（因为危害程度不一定一样），但至少这可以提供一个参考基准——至少苹果不是生来就安全的，而且也需要定期修复大量的内核漏洞。只是因为iOS修补漏洞比较全面和及时，让人感觉它非常“安全”。同样地，“Android不安全”并不是仅仅因为漏洞频发，更重要的还是不能像iOS这样及时地修复问题。

　　为何Android内核漏洞得不到及时修复？

　　第一，Android的产业链过长：Android生态系统产业链非常长，从硬件厂商，到Google，到手机厂商，再到运营商。每一个环节都有自己的开发、质控、验证等复杂流程，有时候还会相互冲突。这样要消耗大量的时间和人力，而且有时甚至导致安全补丁无法下发给用户。这个冗长的修补链条如图2所示。

　　第二，Android系统碎片化过于严重：Android系统的碎片化是指世界上所有Android用户实际使用的Android版本、配置、驱动等等有着非常显著的差异。Android系统碎片化已经成为了业界共识，由于系统的开源性，用户、开发者、OEM厂商、运营商都可以按照自己的想法进行改造，这种“碎片化”的程度异常严重。在这种情况下，大多数手机设备厂商已经失去了为所有用户使用的Android系统提供安全补丁的能力。图3所示为繁多的Android品牌和机型。

　　根据Google官方发布于2016年7月的统计[6]：

　　1.Lollipop（Android 5.0）发布于November 2014，但是仍然有55%的设备低于该版本

　　2.Google已经停止为低于4.4版本的Android提供补丁，但仍有23%的设备低于该版本

　　而在中国，由于对Google的访问被阻隔，这一问题更加严重。通过随机采样大约200万装有BaiduApp的设备的手机，我们发现：

　　1.80%的设备低于Android5.0

　　2.42%的设备低于Android4.4

　　第三，生态职能不匹配：其实最容易推进修复的是手机厂商，但大部分手机厂商自身的碎片化现象非常严重，导致了手机厂商没有足够的资源和精力去修复漏洞。而对于安全厂商来讲，修复漏洞也是一件很尴尬的事情。在正常情况下，安全厂商是没有系统授权的，除非先进行root。即使root，安全厂商仍然要面临不同手机品牌更加严重的碎片化挑战。

　　案例分析

　　具体看3个著名的能被用来进行跨平台root的漏洞：第一个是CVE-2014-3153（Towelroot），公开和修补时间为June3，2014[7]；第二个是CVE-2015-3636（Ping Pong Root），公开和修补时间为September9，2015[8]；第三个是CVE-2015-1805，公开时间为April3，2014[9]，但直到March18，2016才在Android平台上修复[10]。图4所示为这三个漏洞距今（2016年7月）的时间跨度。其中最短的也达到了120天。

　　图5所示为这三个漏洞在装有百度App的手机上的随机采样结果。可见虽然这么长时间过去了，仍然有非常多的设备没有得到漏洞修复。

　　AdaptKpatch：自适应内核热修补框架

　　如何解决Android漏洞得不到及时修补的问题？对于跳过冗长补丁链这个问题，学术界工业界已经给出了一些方案，比如kpatch[11]，ksplice[12]，kGraft[13]，Linux upstream的livepatch[14]，但是这些方案并没有解决碎片化和能力失配的问题。更本质地说，这些方案都依赖源码，对于没有源码的第三方不适用，更遑论补丁的广泛适配。因此在第七届HITB会议上[15]，我们提出了内核自适配修补的方案，称作AdaptKpatch。其大致流程如图6所示。

　　简单来说，该框架在手机上探测存在的内核漏洞，向用户征询是否修复。得到允许后，该框架root手机并收集必要的信息，包括kernel versions，symbol addresses，symbol CRCs等。取决于设备是否提供insmod或者（k）mem设备，框架会下载对应的模板进行数据结构填充和symbol解析，并视情况对内核的一些动态校验机制进行放宽。这些步骤完成后即完成补丁模板的适配，所生成的补丁即可插入该设备的内核执行修补操作。具体的修补操作和其他热修补方案无异，比如函数替换、调用替换、原地修补等，此处不再赘述。注意该框架只是热修复，因此每次重启都要重新加载热补丁。如果某次启动发现前次启动因为热补丁而出现崩溃，则放弃加载热补丁回滚到正常启动。

　　如果手机厂商愿意和第三方协作修复时，该框架可以最大化发挥效益。厂商不再需要花资源和精力修补漏洞，只需要提供预制的内核修补机制/能力，而安全厂商不需要再root手机和探测漏洞，可以专注在修补漏洞上。这一合作模式如图7所示。基于这一合作联盟，可有如下安全机制保证补丁的安全。

　　1.厂商资质校验：只有有能力和名声好的厂商方可进入合作联盟，各厂商所发补丁需签名验证；

　　2.补丁审计：补丁发放前需要经过联盟里别的厂商进行安全审计，防止引入新的漏洞或者后门；

　　3.评价排名：类似于App Store，用户可以对某个补丁进行稳定性等方面的评价。其他用户可以根据补丁的既有评价选择打还是不打。