iOS 12完美越狱来了!漫谈iOS 12缓解机制

是以可以对正在应用的snapshot改名!经由过程这个破绽将snapshot改名后,reboot时系统找不到蓝本注册的snapshot,被迫应用真实的/dev/disk0s1s1进行mount

每年iOS系统大年夜版本进级,对付安然钻研职员都是一次新的寻衅在大年夜版本中,除了修补一些未经公开的破绽外,苹果还会增添新的缓解机制,大年夜大年夜前进了全部逃狱的难度这不仅要求安然钻研职员能够掘客出可以自力提权的破绽,还要能够攻破署名绕过和根目录读写这两道关卡在iOS 12中,业界公开的办理规划都已经被苹果封堵

0×01 署名绕过(CodeSign Bypass)

在iOS中有异常严格的署名校验机制,所有宣布的App均必要经由过程苹果揭橥的证书进行署名之后才能上架因为存在TeamID机制,即第三方动态库与宿主进程应用同一个证书署名,纵使经由过程破绽使用完成提权后,依然无法运行未署名的binary,也无法注入代码到其他进程,是以必要绕过苹果的署名校验在iOS11中,业界有两种公开的办理规划:

(1). 挟制署名校验进程amfid(hijack amfid @i41nbeer)

iOS系统中经由过程AMFI的Mach Message调用用户态进程amfid进行署名校验,此中MISValidateSignatureAndCopyInfo函数返回署名校验结果和CDHash(Code Dictionary Hash)到内核

在iOS 10曩昔,MISValidateSignature可以经由过程简单地返回一个布尔值完成绕过iOS 10今后,MISValidateSignature*函数的返回值为字典Google Project Zero的安然钻研职员Ian Beer提出的办理规划是经由过程挟制amfid的exception handler,并把MISValidateSignatureAndCopyInfo函数指向一个无效地址,从而使得每次进行署名校验时amfid都邑发生exception,终极回调到挟制的exception handler从回调函数中获取到binary信息并精确返回CDHash,经由过程全部校验逻辑如图1-1所示

图1-1 挟制amfid绕过署名简略单纯流程图

在iOS12中,内核增添了CMS(Cryptographic Message Syntax)校验,而业界常用的自署名对象ldid以及jtool中CMS都是为空的,导致上述办理规划掉效同时内核增添了CoreTrust模块用于抗衡hardcoded证书,是以要捏造署名并经由过程苹果校验的难度大年夜大年夜前进

(2). 捏造署名授信缓存(fake trust cache @Xerub)

内核中AMFI应用trust cache快速校验ad-hoc的binary,它是一个链表式的数据布局,并且寄放的位置不受限于KPP/AMCC的保护,提权完成之后可以在内核中找到这个布局体,插入自署名binary的CDHash绕过署名校验

在iOS12中,已经无法从AMFI中找到trust cache chain了,他被寄放在内核的const data段中,这意味着无法对他进行改动系统经由过程调用pmap_lookup_in_static_trust_cache进行校验

然而当我们仔细钻研AMFI中的署名校验逻辑时发明,内核中有2个trust cache chain,校验时分手对这两个trust cache进行检索匹配,只要经由过程此中一个校验即可,虽然上述static trust cache chain无法改动,然则别的一个依然可以改动!并且binary经由过程trust cache的校验后,无需再进行CMS校验!苹果虽然考试测验封堵这种绕过要领,但依然存在破绽,导致新增添的缓解机制被轻松绕过

0×02 根目录读写(Root Filesystem Read / Write)

在iOS中为了保障手机文件安然,纵然进程拥有Root权限,依然无法改动Root Filesystem的内容iOS 11.3对Root Filesystem有过加强,从而令从新挂载Root Filesystem后,改动Root Filesystem会触发内核panic在iOS 11.3后根目录读写的办理规划有两种:

(1). 捏造有效的mnt_data(Xiaolong Bai and Min (Spark) Zheng @ Alibaba Security Lab)

在iOS 11.3中,纵然把RDONLY的标志去掉落使Root Filesystem能被挂载为可读写,但因为挂载的是一个只读的snapshot,并且snapshot中的mnt_data 不包孕有效的extent布局,是以改动Root Filesystem会触发内核panic那办理的规划自然是将snapshot remount的mnt_data调换为一个有效的mnt_data苹果在iOS 12的APFS中进一步加强了对mnt_data合法性的校验,用上述措施直接调换会触发内核OOM Panic

(2). 删除/dev/disk0s1s1 snapshot (cererdlong and eakerqiu @ Alibaba Pandora Lab)

对付snapshot的另一种办理规划是直接删除经由过程删除/dev/disk0s1s1的snapshot,使得reboot时系统无法加载对应的snapshot,终极被迫系统应用真实的/dev/disk0s1s1进行mount

虽然苹果在内核有对fs_snapshot_delete进行校验,无法将正在应用的snapshot直接删除,但却没有对fs_snapshot_rename进行校验重启完成后,不仅可以直接将改名的snapshot删除,而且可以经由过程简单改动mount的mnt_flag直接mount update根目录为可读写

苹果在iOS 12的APFS对这个破绽也进行修补,使得正在应用的snapshot无法被rename只管如斯,依然有新的思路和措施可以挂载根目录为可读写

0×03 结论

苹果在iOS 12中修复了很多未公开的破绽,增添了新的缓解机制,但在iOS 12正式版宣布的数小时内,潘多拉实验室完成了iOS 12的完美逃狱,如图3-1和3-2所示从技巧的角度来看,完美逃狱和非完美逃狱的主要差别在于重启历程中是否能自动履行逃狱代码,在手机重启完成前完成逃狱

图3-1&3-2 iOS 12节制内核PC完成逃狱并安装Cydia

赞(0) 打赏
分享到: 更多 (0)
免责申明:本站所有资料均来自于网络,版权归原创者所有!本站不提供任何保证,不保证真实性,并不承担任何法律责任

评论 抢沙发

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

阿里云优惠网 更专业 更优惠

阿里云优惠券阿里云大礼包