神刀安全网

[Android ROOT技术]深入浅出adb setuid提权漏洞RageAgainstTheCage

ROOT Android系统的设备一般和越狱Apple iOS系统的设备类似,都是为了获得整个设备任意区域的读写控制权,使得用户可以在任意区域读写文件,包括操作系统区域,ROOT Android系统即为能使普通用户获得ROOT权限使用该Android设备。

普通用户获得ROOT权限后使用Android设备可以帮助他们越过手机制造商的限制,也可以卸载手机制造商预装的应用程序,甚至可以替换该设备的操作系统(ROM)。但ROOT过的Android设备可能会因为误操作,应用软件的恶意行为导致设备不可用,甚至存储在设备中的个人隐私及财产遭受威胁等。

本文不会探讨ROOT设备随后带来的风险,而将会着重探讨多种ROOT技术的一种,深入浅出该技术是如何利用Android系统发布初adb setuid提权漏洞去ROOT设备的。

漏洞信息

CVE: CVE-2010-EASY

Affect: 2.2.3及之前,Fixed:2.3.6

漏洞代码: /system/core/adb/adb.c

/2.2.3/system/core/adb/adb.c adb_main

[Android ROOT技术]深入浅出adb setuid提权漏洞RageAgainstTheCage

(代码1 2.2.3系统漏洞代码定位)

/2.3.6/system/core/adb/adb.c adb_main

[Android ROOT技术]深入浅出adb setuid提权漏洞RageAgainstTheCage

(代码2 2.3.6修复之后的漏洞代码)

下述漏洞代码都基于2.2.3,修复之后的代码基于2.3.6。

众所周知,Android系统是基于Linux系统的,所以不管是利用Android系统原生漏洞还是手机制造商定制而出现的漏洞,ROOT技术万变不离其宗 都是将 su 文件复制到Android 系统/system/xbin 目录下,将所有者更换成root 用户,并用chmod 命令设置为可执行权限和setuid(s) 权限

(1)可执行权限,即该文件可以被执行,包含所有用户都可以执行的权限,即755,命令为chmod 755后加文件名;

(2)setuid(s)权限,即该文件可以被任意用户以文件所有者的身份执行,比如一个文件的所有者是root用户,如果该文件具有setuid(s)权限,那么任意用户都可以运行它,并且是以root用户身份.执行ROOT操作时,su文件的所有者是root用户,但其因为被设置了setuid(s)权限,该文件可以被任意用户以root用户身份运行,命令为chmod 4755后加文件名。

adb工具原理及介绍

这个2010年出的漏洞是利用adb工具进行破解的,所以在此之前我们需要了解adb工具工作的原理: 开发者拿到的Android SDK包含了adb工具,该adb工具其实包含了client端和server端,并且我们的设备端有adb的守护进程adbd程序在运行,当我们使用adb client向adb server发送命令时,adb server会连接设备的adbd程序,由adbd程序执行开发者传过来的命令。即我们开发者使用adb命令操控设备其实是透过协议将命令传递给adbd,由adbd替我们完成命令。

[Android ROOT技术]深入浅出adb setuid提权漏洞RageAgainstTheCage

(图1 通过ps命令显示Android adbd进程)

从上述adb工具工作原理过程中,我们可以得知:

(1)adbd程序是由Android设备在开机时就应该准备好的,不难猜测这个adbd程序是通过配置rc中的系统服务由init进程开机自启动的,我们可以查看init.rc内容:

[Android ROOT技术]深入浅出adb setuid提权漏洞RageAgainstTheCage

(图2 通过cat命令查看显示Android init.rc文件)

init.rc果然有adbd启动这一项,所以我们这个猜测是正确的。

(2)正如上述,我们在外部使用adb client最后都会被adbd程序运行,所以说adbd的进程权限决定了adb命令的权限。

但是配置在init.rc中程序有init进程启动之后应该都是以root身份运行的并且具备root权限,而我们从图一可以看出在未ROOT过的手机中adbd程序却是以shell身份运行的,对于Android系统设计者来说这是无可厚非的,因为这样可以避免使用adb直接以root身份操控设备,但这是怎么实现的呢?

adbd进程切换用户

[Android ROOT技术]深入浅出adb setuid提权漏洞RageAgainstTheCage

(代码3 跟踪/2.2.3/system/core/adb/adb.c adb_main函数)

来,跟踪代码,发现adb_main函数会从default.prop中获取ro.secure值,并根据此值去做切换用户操作,如果ro.secure为1则切换,否则不予切换,事实上设备出厂的时候在/default.prop文件中都会有将ro.secure值置为1,所以我们未root过的设备adbd命令都被从root用户切换成了shell用户了。

Leverage adbd

本文一开始就介绍了root的终极目的,就是复制su文件到指定位置并且赋予可执行权限和setuid权限,但是这一过程本身就需要拥有root权限,所以我们可以考虑能否在adbd进程启动上打点注意呢?因为init进程在启动adbd进程的过程中在执行setgid和setuid代码之前一直都是拥有root权限的,如果我们让setgid和setuid执行失败,那岂不是adbd会一直拥有root权限。

[Android ROOT技术]深入浅出adb setuid提权漏洞RageAgainstTheCage

(图3 init进程启动adbd进程示意图)

从漏洞代码可以看出adbd在setgid和setuid的过程中,并未检测降级是否成功,所以hacker只需要阻止或者破环这个降级过程,就可以达到使adbd进程以root用户的运行的目的,从而使得外部adb client拥有root权限运行一切命令的能力,ROOT过程就自然水到渠成了。

PoC知识准备

查看setuid函数,寻求找到失败的突破口,直接man下setuid,获得下述文档:

[Android ROOT技术]深入浅出adb setuid提权漏洞RageAgainstTheCage

(图4 Linux man 2 setuid 帮助文档)

文档指出setuid是可能发生错误的,如在目标用户的进程数超过RLIMIT_NPROC限制时,系统就不能再将一个进程分配给这个目标用户,并会发生EAGAIN错误,如果直接忽略这个错误的话,则adbd仍继续以root用户运行。

所以我们需要继续研究RLIMIT_NPROC这个值,这个参数是Linux为了均衡多用户通过使用shell命令使用系统资源设定的,Linux系统替每个用户限定了最大进程数目、最多内存使用、最多打开文件数目等系统资源的使用,这个RLIMIT_NPROC即为通过shell每一个用户最多打开进程的数目,我们可以通过ulimit -a 来查看。

[Android ROOT技术]深入浅出adb setuid提权漏洞RageAgainstTheCage

(图5 HTC one设备每个用户通过shell使用资源限制情况)

比如这台HTC one手机就允许每一个用户打开12408个进程,打开1024个文件,拥有262144KB内存等系统资源。

PoC执行方案

  • 使用shell用户登录设备,获取shell用户的可以开启的最大进程数目RLIMIT_NPROC;
  • 制造大量进程并达到shell用户的RLIMIT_NPROC,并占据不释放;
  • Kill当前已经存在的adbd进程(该adbd进程已被降级成shell用户);
  • 再次创建一个进程用来占据进程数并不释放;
  • 等待系统重新创建adbd进程,在创建过程中adbd一直为root用户进程,但在setuid时切换至shell用户失败;
  • init进程不会检查切换用户是否失败,而将继续以完成adbd进程的创建工作,最后创建出仍以root用户为所有者的adbd进程;
  • 退出shell用户,在推出之前清除多余进程,然后以adb client命令的形式完成su文件复制,权限设置,授权apk的安装等ROOT步骤。

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » [Android ROOT技术]深入浅出adb setuid提权漏洞RageAgainstTheCage

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址