CHEREB

CHEREB is a FLOSS( free/libre open source) based defensive security solution.

Its main objective is to provide a total solution from the angle of fundamental security ecosystem, in order to build an unified platform to enable system convergence by applying the core concept of security by design.

We provide open source consulting solution for data center based on Debian, e.g: Automation, High Availability, Virtualization, Cluster Storage etc. Debian GNU/Linux is a community-driven distro with numbers of high quality packages.

Based on the progress of PaX / Grsecurity, a huge amount of effords have been devoted from the aspects of compiler security, kernel level protection, TEE, standard library and framework security, vulnerability analysis, threat intelligence analysis and assessment, operational security, best practice of system deployment process, scenario analysis, and system design, to implement an optimized secure ecosystem.

The ecosystem provides a glueing logic platform to converge servers, clients, mobile terminals, IoT nodes and gateways, and interoperability devices, by the mean time to ensure the security of the entire ecosystem.

The security by design approach of the new ecosystem not only accelerate the system deployment process, but also mitigate the risk from design to production, which is liable to induce a huge amount of a variety forms of losses.

In addition, it is undoubtedly a stimuli to increase the time to market of an individual product, subsystem, system, or ecosystem from all the perspectives.

The symbolic meaning of CHEREB is about the adoption of an excalibur to cut off all the unauthorised or informal path between the god (kernel) and human being (application).

Android 智能终端操作系统内核安全加固

我们的加固方案

Android设备与Linux内核

      Android从一开始选择Linux kernel作为内核时,就注定了沿袭了Linux的分层设计模型。从传统的分层方式,从内核到用户空间只有两层,相对应Android设备就是Linux内核和ROM以及apps的用户层。由于基于安全方面去考虑,我们把内核空间的动态加载的内核模块也分离开来进行讨论。最上层的ROM是承接内核提供的接口,提供面向应用的接口,applications利用这些接口,来进行上层应用软件的开发,安全产品在这一层的是以应用软件app的形态存在的,类似于杀毒软件,清理软件。内核模块这一层,和kernel运行在内核空间,通常是实现代码供内核主动或被动调用,安全产品在这一层,需要取得最高权限root,加载插入内核模块作为补丁,来进行安全防护。最后一层,也就是我们方案加固的这一层,是内核层,我们的方案是针对内核本身一些基础设施,例如一些内核的api,一些常规操作进行加固,加固后直接放在Android树中编译,无需提供root,是针对内核本身的防护而不是一个独立于Android的软件或者补丁。

在Android各个层面上做加固的区别

在上述三层中做加固都有各自的特点。
应用层
      安装在应用层的安全产品,特点是:硬件无关的,可以跑在大多数Android设备上,有一定防御作用;另外一方面,作为第三方软件,面对能够拿到root的漏洞利用,本身权限低,就有可能被攻击者控制或者删除,也就失去防御作用。反倒是在垃圾清理,通讯录信息安全,app检查这类比较有作为。而系统安全,防提权,防root上,效果并不明显。
内核模块
      这种方案的特点是,要求手机厂商提供root权限。在这个基础上将防御补丁(内核模块)插进内核。实现防御。需要厂商的root权限开放,等同于让手机厂商和安全方案厂商共同管理安全问题,也正因为权限的提升,防御要相对有效。
内核加固
      这也是我们方案采取的加固方式。特点是:基于内核源代码本身的加固,无需任何权限。由于是针对内核本身代码加固,对提权漏洞的防护特别有效。这种加固方案需要手机厂商提供手机的内核代码,才能进行加固,加固后的代码由手机厂商自行放进Android编译树中编译,不存在第三方软件,不需要手机厂商提供任何权限。

安全补丁or安全特性

      上一个小节我们是从加固方案所处的层级,所需权限和产品形态进行安全产品的对比。另一方面,还要从针对漏洞的角度去考虑一个安全产品的能力。
安全补丁
      安全补丁,针对漏洞的修复,像Android设备,最常见的就是由手机厂商推送安全补丁。比如一个漏洞曝光,厂商确认存在漏洞的机型,针对机型推送安全补丁给用户,要求用户安装更新。这种推送补丁的方式,是针对单一漏洞进行的修复,也是终结一个漏洞的最终方式,但是面临的是Android碎片化和补丁链过长的现状(下文会提及),不仅适配调试补丁的成本巨大,更因为时间周期长导致有一段危险期。危险期前是漏洞尚未被发现,危险期间是对已知漏洞的补丁的适配调试到推送等,危险期后是安全补丁已经推送出去并且落到用户手机上,这时已经有了该漏洞防护。危险期间是毫无防护能力,异常危险的。
安全特性
      而所谓安全特性,和针对个别漏洞进行的修复工作是完全不一样的。像在我们的方案中,包含了诸多安全特性,而一个安全特性对应的常常是一整类漏洞的防御。比如PAX_USERCOPY特性,所针对的是用户空间和内核空间数据拷贝时溢出的这类漏洞;而像PAX_ASLR和PAX_PAGEEXEC则是针对漏洞被利用时,攻击者执行任意代码的防护。可以这样说,在已知漏洞存在,而厂商由于各种原因没法及时把补丁推送到用户手机的这段时间内,安全特性能在不知道具体漏洞的细节的情况下,拦截下大多数的大规模漏洞利用。
      这就解决了上述漏洞补丁推送过程存在危险期的问题。危险期前,期间虽然漏洞存在,但是我们的内核加固方案在此期间能够提供内核防护,使得漏洞不足以形成大规模漏洞利用,无法获取root权限。在补丁完整测试完完全推送到用户手机(不影响功能的时候甚至可以选择不修复补丁,但我们不建议),漏洞的周期也就结束了。而这个周期和我们的防护方案是毫无关系的,因为我们不是针对漏洞的补丁集,不关心具体补丁,在手机出厂时就终身自带防护了。

Pax/Grsecrity、KSPP

      PaX/Grsecurity是一组针对Linux内核安全加固特性,PaX/Grsecurity使得Linux的安全性更进一层。 KSPP( Kernel self protection project)从2015年11月Linux系统安全性被披露以后开始组建的。这是公众第一次意识到Linux的安全问题或将危及移动设备平台(Android)和物联网设备。KSPP尝试将Pax/Grsecrity一些加固特性实现移植到Linux上游。对于Android设备和用户而言,KSPP是非常重要的,因为AOSP内核的安全走向很大程度会依赖于KSPP的走向。

我们的方案

      总的来说,我们的方案是:基于Pax/Grsecrity,把这些针对内核的安全特性移植到Android设备(ARM)的内核中,在构建手机rom时使用已加固的内核代码,使得手机的安全性大幅提高,防御各类漏洞,防止Android设备被root。
      这部分的加固特性,主要是Pax关于内存的特性以及一些代码级加固。比如关于栈不可执行有PAX_NOEXEC、PAX_PAGEEXEC、PAX_MPROTECT,防止引入攻击代码。随机化则有PAX_ASLR、PAX_RANDUSTACK、PAX_RANDKSTACK,打散内核和用户空间的内存布局,防止被猜透地址代码复用。为了防止设备驱动栈溢出则移植了PAX_USERCOPY。PXN则拦截了常见的ret2user。PAX_REFCOUNT用于防御计数溢出。代码级加固如Infoleak prevent配合防止一些内核敏感信息的泄漏。有了这一批加固特性,绝大多数的大规模漏洞利用都可以轻易的被拦截,对于厂商而言成本也很低,成效也很明显。

为什么需要加固

从Linux社区到Linux安全再到Android安全

      由于Android使用Linux内核作为内核,而且越来越多的嵌入式设备选择了Linux内核,选择了Android,因而Linux内核本身的安全,已经影响到Android设备。长期以来,Linux社区一直对bug持有“bug is a bug”的态度,对于安全问题有回避的意味。而15年末开始的KSPP计划,尝试着将Pax/Grsecrity的一些特性主线化。而Android设备通常使用了版本较低的内核,也就是享受不到KSPP的一系列安全特性。而我们所做的方案恰恰也是对这部分缺少的弥补,针对具体的机型进行安全特性的移植。

Android推送补丁链条

      Android设备的补丁推送链条很长,这是导致在漏洞在Android设备上很有利用空间的原因之一。
      上文已经提及,漏洞曝光以后,补丁的开发,测试,推送期间,设备处于毫无防护的状态,是最薄弱的。其实,现实状况比这要糟糕的多,原因就是andorid的补丁链过长,导致补丁开发到推送的时间变得十分漫长,给漏洞利用留下充裕时间来。

      首先是漏洞的研究发现或者曝光,接着是Google首先对AOSP源码进行补丁的开发。手机厂商或者其硬件提供商,会跟随Google进行补丁开发或移植。然后手机厂商才能拿到补丁对具体机型进行适配调试等工作,直到将补丁推送出去。接着被推送的补丁还需要用户去做更新,否则补丁推送出去后并不能落实到手机上。这才完整地结束整个漏洞的周期,手机才脱离危险期。
      而且值得注意的,不能排除硬件厂商没有推送补丁到手机厂商,这也意味要么手机厂商需要自己跟补丁,要么只能任由攻击。
      我们可以看到整个过程中,补丁推送期间给攻击者留下了很长的空缺,使得手机完全暴露在危险之中。如果在这段时间用户的Android设备被攻击者拿到root,那后续的补丁,已经没有任何意义。而我们的方案,由于在出厂之时已经为内核代码进行了加固,即便是存在漏洞,也无法进行大规模漏洞利用。这就在时间上缓解了危险期(就算漏洞未被发现曝光也在防护范围内)毫无防护的状况,解决时间上的难题。

Android的碎片化

      Android设备的碎片化问题已经非常明显。无论是Android设备的配置、驱动,还有个手机厂商根据需要对AOSP本身代码的修改,碎片化十分严重。碎片化问题的存在,使得硬件厂商,手机厂商在安全补丁的推送方面,遭遇了很大的挑战。本身补丁需要做针对性的适配,并进行测试验证,碎片化使得手机厂商需要维护的手机型号异常的多,维护成本也十分高昂。最重要的是,由于维护工作量大,必然拉长了适配测试补丁的时间线。也就是说,暴露在攻击者面前的危险期变得更长,手机被攻击,被root的可能性也就大大的增加了!

国内GooglePlay的缺失

      另外一方面,由于国内的GooglePlay这个角色的缺失,应用软件不规范,恶意软件,root工具横行,使得中国市场的android设备状况雪上加霜。
      比如一些root软件,在GooglePlay是没法通过审查上架的。用户没法在应用商场下载到,不会引入这种提权的攻击。而国内则是用户可以 随意的在各种app市场获取这些恶意的软件,除去手机厂商自身的应用商场,还有各种第三方的应用商场。手机厂商本身维护审查应用的成 本 也是很高的,再加上第三方应用商场不规范的软件,以及各种代码质量低下的软件,被攻击风险大大增加。

加固方案实现综述

Android设备漏洞与提权
      所谓漏洞,指的是在已经运比较行的Android设备上,存在某种软件上或者硬件上的缺陷,导致存在被攻击者攻击、利用。攻击者的目的多种多样,有可能导致正常功能无法使用,也有导致个人信息、隐私泄漏等。而一种多的情形是,攻击者利用漏洞提升到管理员权限(root),然后进行更多的恶意操作。
      而作为整个Android硬件资源的分配,内核拥有着最高的权利。因此内核的代码质量,bug的存在,对漏洞利用提权有着至关重要的地位。实际情况却是,我们根本没法在Android碎片化的生态环境下去改善具体设备的软硬件。而我们的内核加固方案,就是一个针对内核本身代码防御漏洞利用攻击的利器。
总体设计
漏洞利用往往会有几个步骤,尽管具体情况千差万别,但是大致归纳如下:

  1. 软件或者硬件本身存在缺陷,有bug,可能可以被利用;
  2. 控制程序执行流指向攻击者的目的代码中,控制执行流方法因bug的类型而不同,指向的代码因目的代码而不同;
  3. 执行恶意代码,达到提权目的;

      PAX_*针对漏洞利用的每一个环节都有相应的防御手段,这些防御手段对于大规模漏洞利用,非定制化的攻击意义非凡。尤其在移动手持设备,解决了Android补丁推送时间轴过长的忧患。

类型 防御手段
堆栈溢出 PAX_USERCOPY
use-after-free PAX_REFCOUNT(仅针对计数溢出)
ret2usr PXN
shellcode注入 PAX_NOEXEC,PAX_PAGEEXEC, …
ret2lib PAX_ASLR,…
infoleak capable(CAP_SYS_ADMIN)

      正如图所示,在漏洞/bug本身这个层面,我们有特性针对像堆栈溢出等这种能破坏堆栈,影响执行流的漏洞的一个防御措施,即使程序存在漏洞,也无法被进一步利用。在控制执行流这一步,重定向目标代码可能处在用户空间或者内核空间,可能是代码构造也可能是代码复用。PXN是针对返回到用户空间去执行的,内核空间的会在下一步进行拦截。第三步就是防止恶意代码执行,主要通过内存不可执行的标志位和对堆栈地址随机化实现。
      除此之外,我们的方案里还实现了一部分upstream的安全补丁,或者针对性的代码加固。比如可以用来配合寻找到可执行内存的infoleak的加固等。

我们的试验结果

以下是我们针对Nexus系列,Pixel和小米手机所做的试验的部分信息:

机型 Android版本 Kernel版本 加固时间
Nexus 6 5.0 3.10 2014.11
Nexus 7 4.4.4 3.4 2014.11
Pixel 7.1 3.18 2017.1
redmi2 5.1 3.10 2016.5

以上各个版本的加固到目前为止,需要打针对性补丁的漏洞只有:

具体实现介绍

PAX_USERCOPY加固特性

简介
      漏洞存在的第一步就是程序存在bug,使攻击者存在对bug进行利用达到自身目的的可能性。而内存溢出破坏栈是漏洞古老而永恒的一种。至少目前一直保持一定的曝光量。PAX_USERCOPY就是拦截bug的第一步,防止内存溢出。
      在linux内核的设计中,内核地址空间和用户地址空间是隔离的,不能直接透过地址去访问内存。因此,当需要发生用户空间和内核空间进行数据交换时,需要将数据拷贝一份到另一个的内存空间中。在内核中copy_from_user和copy_to_user这组函数承担了数据在内核空间和用户空间之间拷贝的任务。
      这就带来一个问题,如果从用户空间拷贝到内核空间的源缓冲区长度(通过参数usigned long n来传递),未加检验的就拷贝到内核空间之中,我们并不知晓内核空间的目的缓冲区是否有足够的长度来容纳拷贝过来的数据。当目的缓冲区小于拷贝长度时,就有可能产生溢出,破坏栈帧,修改内核空间数据等,就会导致可利用漏洞。
      解决这个问题的一种常见方法是依靠程序员在编写代码时小心翼翼的去保持拷贝行为不会溢出,然而在Android设备碎片化极其严重的情况下十分困难,因为各种各样的设备驱动代码极多,代码质量较差的,这也是驱动成为漏洞的重灾区的原因(这对函数在设备驱动中使用极多)。
      PAX_USERCOPY则在这组函数中实现了缓冲区的长度检查,当长度检查发现有溢出的可能时,就不会执行数据的复杂,防止非法拷贝覆盖内存,破坏栈帧。

设计实现

      内核调用copy_from_user和copy_to_user实现在用户空间和内核空间的数据传输。这组函数又分别由__copy_to_user和__copy_from_user包装而成。我们的加固思路是,__copy_to_user和__copy_from_user这一层进行复制长度的检验。将加固放在这一层的优点是:无论溢出代码存在于内核中的那个设备驱动或者哪块代码,都由于调用了函数而被探测到,因此不必担心漏洞被利用,只需从容的做好补丁,修好bug恢复正常功能即可,不影响功能的bug可斟酌不修。
以向内核复制数据为例,具体的设计思路是,在函数中插入检查代码,代码分以下两种情况:

  1. 若指针在堆中,检查复制数据是否会溢出到非分配区域
  2. 若在栈中,检查复制数据是否将会溢出到非当前栈帧中

以检查栈为例,可分以下三种情况

      经过这样的检查,溢出破坏栈帧的行为都会被检测到并且拦截下来。作为漏洞利用的第一步即被拦截,后续的漏洞利用更是无从谈起。

PAX_REFCOUNT加固特性

简介
      PAX_REDCOUNT是针对引用计数溢出的加固。内核对象的引用计数不断增加,当发生溢出时,引用计数为0,内存即可被释放,而此时程序还保持对该指针所值内存的引用,就有可能发生use-after-free攻击,被用作漏洞利用。该特性能够探测处理溢出的发生。
use-after-free攻击
use_after-free是指使用已经被释放的指针,造成crash或者任意代码执行。漏洞产生的条件是,引用的指针已经被free掉,这说明了:

  1. 该指针应用计数为0,才能对其进行free释放内存;
  2. 仍有指针指向被释放内存,也就是实际上指针引用不为0;

      以上两者共存的一种已知情况就是引用计数溢出时,引用计数超过变量最大值就会变成0,内存可被释放;而此时计数是增大溢出为0,而不是减少为0,也就是说仍有指针指向使用这段内存。所以可以说,计数的溢出是此类漏洞存在的关键点。
      CVE-2016-4558是一个典型的use-after-free漏洞攻击例子,该漏洞是在内核的BPF子系统之中。inode.c、syscall.c 、verifier.c代码中调用atomic_inc对refcnt变量进行逐加的原子操作,而对计数不加检查,于是发生了计数溢出,产生可利用漏洞。

设计实现
解决这种类型的大规模利用有两种办法:

      这两种实现的差别是,前者在具体漏洞曝光时,需要这对特定漏洞所处的代码进行修补。也就是只有知道漏洞时才能针对漏洞进行挨个修复的工作,目前大部分厂商使用这种办法。后者的实现显得十分优雅,由于计数的原子操作都需要使用atomic_*族函数,在函数中插入行溢出的条件跳转,但凡在内核代码中使用原子操作函数的地方,都会自动进行这项检查,溢出都可以被探测到。因此,无论漏洞披露与否,无论漏洞代码身处何处,都没法逃过检查,也就无需因为安全问题而另外打补丁。

我们方案中采用的PAX_REFCOUNT是后面一种的强悍实现,包括两部分实现:

  1. 加固atomic_*族函数,探测溢出的发生
  2. 溢出发生时的异常处理

      探测的实现如前文所述,用一个bvc汇编指令,实现溢出与否的分支跳转。当溢出发生时,使用bkpt陷入异常处理。异常处理则会结束该进程,然后触发grsecurity的用户封锁机制。使得漏洞不会被进一步利用。

Privileged execute-never(PXN)

简介
      PXN是一个防止用户空间代码被内核空间执行的安全特性。在ARMv7的硬件支持下,通过PXN比特位的设定,决定该页的内存是否可被内核执行,可有效防止ret2usr攻击。
ret2usr攻击

      在Linux的设计中,用户空间和内核空间是分离开的,如右图,上半部分代表内核空间,下半部分代表用户空间。当内核代码存在bug或者漏洞的时候,攻击者利用漏洞控制了程序的执行流,使其执行用户空间的代码,而此时程序具有内核态的权限,就能达到提权的目的,这种攻击方法称为ret2usr攻击。攻击者在实现用户空间代码执行的时候有两种选择:

设计实现

无论上述的哪种情况,利用成功离不开三个条件:

  1. 内核代码的bug导致指针的重定向;
  2. 指针重定向到用户空间;
  3. 执行用户空间的代码达到目的;

      而PXN就是从链条的第二步进入第三步时入手,斩断漏洞利用的利用路线。PXN的实现是通过一个标志位,判断代码是否能被内核执行。像重定向到用户空间的这种情况下,判断位设置为内核不可执行,那么当漏洞利用刚到第三步时,就会触发异常,使漏洞利用中途夭折。
      由于PXN特性在ARMv7中已经硬件实现了,内核所需要做的只是针对硬件去编程,支持PXN设置即可。包括两点,一是确定PXN标志位的硬件信息,二是内存初始化时对标志位的设定。

PAX_NOEXEC、PAX_PAGEEXEC、PAX_MPROTECT特性

简介
      PAX_NOEXEC、PAX_PAGEEXEC、PAX_MPROTECT这三个特性是为防御堆栈,数据段中的任意代码执行的情形而设计的。
      在漏洞攻击利用中,内核不存在攻击者所需要的恶意代码,为了完成漏洞利用的第三步,攻击者需要自己在数据段中构建代码(如shellcode),然后将程序执行流定向到这段代码里,实现攻击利用,提权等。
      这三个特性是通过内核对内存操作的页机制,标识页的可执行,可写入与否,以及探测他的类型转换,来避免攻击者构建在数据段的代码的运行,防止漏洞利用。
设计实现
      这三个特性并不是独立存在的,而是互相配合来形成加固的。PAX_NOEXEC负责实现在页管理机制中插入自己的标识位,供后续安全特性的使用;PAX_PAGEEXEC负责的是页不可执行的具体实现,包括初始化设置页和执行时检测标识位;PAX_MPROTECT则保证了页权限不会发生有安全风险的转换,比如一个可执行页应当不可写,可写可读的数据部分不能转化为可执行等,这都是不允许的。
PAX_PAGEEXEC
      PAX_PAGEEXEC是页不可执行的具体实现,PaX 利用这一点来实现基于页的权限实现。
PAX_MPROTECT
      系统调用sys_mprotect用于对已经被映射的页作出权限变更,PAX的实现是在系统调用的层面上,检查权限状态的变化是否违规。如以下情况:

都会被阻拦,防止页权限往不安全的状态转化,否则仅仅靠对flag的标定来确定权限,很容易被bypass。

PAX_ASLR、PAX_RAND*

简介
      上节介绍了漏洞利用第三环执行恶意代码中注入代码到数据段的防护手段。这一节介绍了另一种攻击手段的防御,即重定向代码到已有代码,进行代码复用实现攻击。在用户空间,ret2libc就是这类攻击的典型范例,当攻击者已经控制程序执行流,而代码注入并执行无法实现时,就会尝试将执行流定向到libc库的代码去,从而完成利用。
      然而要将执行流定向到特定代码中去,首先需要知道那段特定代码所在的位置,即代码的地址。在没有开启内存地址随机化的年代,共享库的代码地址在程序内部的虚拟地址空间是一样的。换句话说,a程序执行到某地址的代码,b进程序行到那个地址是代码也是同一份。这样攻击者就能通过一个程序,去获知所有程序中共享库的内存布局,也就能够很快猜出特定代码的地址,完成重定向执行流。
      针对这种攻击,PAX实现了内存地址的随机化。在每个程序之间,他们与共享库代码的映射关系是不同的,使用的地址也就不同。包括堆栈的起始点也进行了随机化,使得程序本身的内存布局不容易被攻击者猜透,攻击变得更加困难。
加固实现
打开随机化,会有如下加固效果:

      这些都是通过在程序初始化做映射时,使内存空间分布随机化,增加攻击难度。
PAX_RANDMMAP
      该特性能够使主程序,库,的地址随机化,还有brk和mmap这类堆管理函数的随机化。任何进程地址空间的安排都基于do_mmap_pgoff函数,这个函数确立了程序映射的地址或者接受一个来自内核的指定地址。而该函数辗转调用最终会使用TASK_UNMAPPED_BASE,确定映射地址。PAX将会针对该常量进行随机化处理,实现地址的随机化。此外,RANDMAP还会对程序执行的地址进行随机化,相关的函数是load_elf_binary()。
PAX_RANDUSTACK
      该特性负责对所有进程的用户空间栈的随机化,分为两步去实现。第一步在程序执行时,do_exec进行内存分配,bprm.p存放着要分配的页,PAX对他进行了随机化。第二步在调用setup_arg_pages(),这个函数用于将物理页映射添加到程序的栈,他会读取STACK_TOP常量来增长栈,PAX会对这个常量进行随机化。

Infoleak prevent

简介
      在/proc虚拟文件系统中,/proc/pid/pagemap记录着每进程地址空间中内存页到物理页框映射关系等信息,每个物理页带有一个64-bit的值

* Bits 0-54  page frame number (PFN) 页框号
...

      其中PFN是一个比较敏感的信息点,泄漏了内存布局的信息,有可能被攻击者利用。
      从Linux内核4.0开始,只有带有CAP_SYS_ADMIN的用户才有权限获得页框号(PFN),v4.0,v4.1打开失败后返回-EPERM,v4.2返回PFN为0。
设计实现
      针对该pagemap的加固,并不是存在可利用漏洞,而是这个文件中存在这敏感信息点常常会被利用来配合其他漏洞进行攻击。特性的实现是从文件的file_operations进行加固,具体是在open操作里面做用户权限的检测,来判断是否让用户打开。在open里面中capable(CAP_SYS_ADMIN)用于验证执行open操作的用户是否为CAP_SYS_ADMIN用户,不是则返回错误。

我们解决了什么?

防止大规模漏洞利用

      我们的方案是在厂商的Android设备的内核源码中进行加固,这意味着自出厂之时,Android设备已经具有了安全防护,能够抵御大多数的大规模漏洞利用。比如我们做过测试(前文述及),几年内需要做针对漏洞的补丁只有一个。这代表着使用我们的方案的设备在众多个危险期期间,大多数的漏洞都无法进行攻击,root软件都没能拿到root权限。这不仅仅在推送补丁的危险期很有意义,在厂家停止维护的机型上也就意义显著,因为厂家几乎只花一次钱就获得了该设备的终身防御功能。

厂商漏洞的修补

      由于我们的加固方案,在不打补丁的情况下,能够防御住大多数的漏洞攻击,那么需要额外打针对性补丁的漏洞少而又少(我们建议厂商还是要跟进补丁)。一方面,我们的加固方案是在补丁推送期间间最具防御的意义,另一方面则是厂商放弃维护的老旧机型。这两者无疑都能降低厂商修复,维护成本。

产品展现

这一部分我们展示以app的形式刷写内核:
一、展示了谷歌原声系统自带的内核的信息点。“Kernel version”可以看到编译信息,表明是谷歌android-build编译的。如下:


二、展示了某root软件成功拿到原生系统的root权限,显示“root成功”。如下:


三、是我们实现的app,用于刷写我们的加固内核。我们的app提供了一些功能:按钮“FLASH_HARDENED”用于刷写我们的加固内核;按钮“FLASH_ORGINAL”则是刷写本地的原始内核;按钮“BACKUP”用于备份当前内核;按钮“RESTORE”用于回滚到上一次备份过的内核。按钮“CHECK”用于确认刷写内核的环境。正常情况下,用户需要先点击“CHECK”确认刷写环境,未报错的情况下点击“FLASH_HAEDENED”刷入我们的加固内核。如下:


四、这是在app刷写成功的图片。首先点击“CHECK”,会显示“Root 有效”和“/dev/block/mmcblk0p14”。因为app实现刷写要有root权限(刷写需要,加固代码不需要),第一个信息点确认权限有效,第二个确认刷写分区的路径。检查成功后,点击“FLASH_HARDENED”,刷写加固内核,成功后显示“Boot flashing report no error”,重启后就能默认运行加固内核。如下:


五、展示了我们成功刷入我们加固过的内核。“Kernel version”一栏有编译相信息,可以看到,这个版本的kernel是我们自己编译的,而不是谷歌原生系统自带的内核。上面也有编译的时间戳,和前面展示的原生内核都是不一样的。如下:


六、展示的是某root软件在我们的加固内核上获取root权限失败的图片。一般在root的过程有可能经历各种重启,这是由于某root软件的恶意攻击行为触发了我们的加固,导致内核panic或者进程被杀死,但是结果都是某root软件没能成功获得root权限。注意:如果加固前被root过,重新加固后,会导致系统的不稳定。如下: