吾爱破解 - LCG - LSG |安卓破解|病毒分析|www.52pojie.cn

 找回密码
 注册[Register]

QQ登录

只需一步,快速开始

查看: 9860|回复: 6
收起左侧

[漏洞分析] task_t指针重大风险预报

[复制链接]
看雪iOS小组 发表于 2017-2-22 12:27
引言:大家都知道知名意大利天才少年Luca放出来的针对<=10.2版本的yalu越狱使用的是对kernel port的buffer overflow拿到了kernel_task_port,本文对类似的task_t指针做出了针对性的分析,从mach端口背景知识,到IOkit的相关处理,最终如何利用在堆栈上写出Exploit,最终甚至给苹果团队给出了修复漏洞的建议,由浅入深,偏辟入里,值得推荐。

本文分三篇推出,分别是分析篇,Exploit篇,和修复建议篇。


译者注:·一些诸如bug,exploit之类的行话选择性的翻译,这通常取决于句子的流畅性。·不确定的地方在括号中附注了原句·超链接附在括号内,方便查看by ruanbonan
分析篇
task_t 指针存在漏洞
由 lan Beer,Project Zero 发布

本文讨论了一个存在于驱动 iOS 和 MacOS 的 XNU 内核核心部分的设计问题。苹果已经发布了两轮缓解策略,紧随其后地,昨天又发布了MacOS 10.12.1/iOS 10.1 中的重大重构(Apple haveshipped two iterations of mitigations followed yesterday by a large refactor inMacOS 10.12.1/iOS 10.1)。我们将关注以下内容:这些bug怎样被利用来进行沙箱逃逸并提升权限;我们如何绕过每一个缓解策略。每一步都配有一个可用的exploit。

一些关于mach端口的背景知识

mach端口是由内核维护的多发送者-单接收者的消息队列。某些特别的mach端口。
提供与用户空间相同的消息传送API,但是发送给它们的消息会被内核消息处理程序同步处理。从这个意义上来说,发给这些端口的消息与系统调用非常像。
任务端口就是这样的一个例子。它们处理那些允许发送者操作一个任务的虚拟内存,并能够访问它的线程的消息。每一个任务有它自己的任务端口。内核占用的消息端口使用MIG这个工具来生成序列化代码。

从底层看IOKit
当在用户空间创建一个新的IOKit用户客户端时,你通常会调用IOKitLib库的以下方法:

kern_return_t
IOServiceOpen(
io_service_t service,
task_port_t owningTask,
uint32_t  type,                    
io_connect_t *connect );

IOServiceOpen调用MIG为io_service_open_extended进程间通信方法生成序列化代码,并把序列化消息发送给已定的IOService端口。mach陷阱mach_msg注意到这个端口被内核占用,并为该消息调用正确的内核MIG处理程序,而不是把它排在端口消息队列的队尾。

这里传来的任务端口是owningTask;这个名字在用户空间和内核代码中相同。它是引起我注意的第一处地方。OwningTask暗示着一个所属关系,这可能导致内核扩展开发者相信IOKit实际在这背后维护了一个所属关系,而这个关系确保userclient的生命周期总由owningTask的生命周期决定。这是一个危险的假设,本篇博客文章是质疑这个假设的结果。让我们来跟随代码流进入内核。下面是一段来自内核里面的MIG为io_service_open_extended生成的反序列化代码片段:

mig_internal  novalue _Xio_service_open_extended(
mach_msg_header_t  *InHeadP,
mach_msg_header_t  *OutHeadP)
{
...
owningTask =  convert_port_to_task(In0P->owningTask.n11ame);
RetCode  = is_io_service_open_extended(
        service,
             owningTask,
             In0P->connect_type,
             In0P->ndr,
             (io_buf_ptr_t)(In0P->properties.address),
             In0P->propertiesCnt,  &OutP->result, &connection);
task_deallocate(owningTask);
...
}

内核已经把所有包含在消息中的权限复制进来,所以In0P->owningTask.name  实际上是指向一个struct ipc_port的指针,而不是用户态看到的mach端口名。
下面是convert_port_to_task:

task_t
convert_port_to_task(
ipc_port_t  port)
{
task_t  task = TASK_NULL;
if  (IP_VALID(port)) {
   ip_lock(port);
   if  (ip_active(port) &&
       ip_kotype(port)  == IKOT_TASK)
   {
     task  = (task_t)port->ip_kobject;
     assert(task  != TASK_NULL);
     task_reference_internal(task);
   }
   ip_unlock(port);
}
return  (task);
}

它检查了port参数,确保是一个任务端口对象,然后通过调用task_reference来对任务提供引用,返回task_t指针。task_t是对struct task指针的别名,从代码中可以看出,它是一个引用计数对象。
这里is_is_service_open_extended仅仅是将owningTask传给::newUserClient:

res  = service->newUserClient(
   owningTask,
   (void  *) owningTask,
   connect_type,
   propertiesDict,
   &client );

newUserClient是一个IOService方法,如果它们想提供多userclient类型,它可以被一个IOService覆盖。否则默认执行在IOKit记录中查询IOService的IOUserClient子类类名,通过IOKit的反射API(链接:https://bugs.chromium.org/p/project-zero/issues/detail?id=221)分配它,并调用它的::initWithTask方法。::initWithTask的默认执行流也不对owningTask做任何处理。

查看代码到此,似乎默认情况下owningTask并不会保有对userclient的引用(这会避免userclient对任务进行引用,形成循环引用,事实却完全相反;如果userclient想要保持对owningTask的引用,它必须对owningTask进行引用——不存在隐式的所属关系。

译者:ruanbonan
原文链接:https://googleprojectzero.blogspot.kr/2016/10/taskt-considered-harmful.html
  原文作者:lan Beer,Project Zero
微信公众号:看雪iOS安全小组 我们的微博:http://weibo.com/pediyiosteam
我们的知乎:http://zhihu.com/people/pediyiosteam
加入我们:看雪iOS安全小组成员募集中:http://bbs.pediy.com/showthread.php?t=212949
[看雪iOS安全小组]置顶向导集合贴: http://bbs.pediy.com/showthread.php?t=212685

本帖被以下淘专辑推荐:

发帖前要善用论坛搜索功能,那里可能会有你要找的答案或者已经有人发布过相同内容了,请勿重复发帖。

C-FBI-QM 发表于 2017-2-22 12:30
吓的我以为又有人装原创了
lookseelook 发表于 2017-2-22 13:25
chenjingyes 发表于 2017-2-23 00:44
liuxia 发表于 2017-2-23 09:38
支持支持,我还是小白一个
yidaozi 发表于 2019-1-5 12:44
由浅入深,偏辟入里,值得推荐
pleaidler 发表于 2019-1-7 18:36 来自手机
支持一下
您需要登录后才可以回帖 登录 | 注册[Register]

本版积分规则 警告:本版块禁止灌水或回复与主题无关内容,违者重罚!

快速回复 收藏帖子 返回列表 搜索

RSS订阅|小黑屋|处罚记录|联系我们|吾爱破解 - LCG - LSG ( 京ICP备16042023号 | 京公网安备 11010502030087号 )

GMT+8, 2024-3-29 21:13

Powered by Discuz!

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表