Apple操作系统-XNU内核下FlowDivert网络协议漏洞分析

首先此处通过connect函数来进行简单分析下调用路径，后续会有用到其中一些内容。

当我们在用户态调用connect函数的时候，系统则会在库里面调用对应的系统调用并进入内核中在内核中，它对应函数的名字依旧是connect()作为函数名，其中三个参数分别是当前进程结构体的引用，以及此处的uap指针则是用户态传给内核态的相关参数，最后则是一个返回值的指针。

进一步进入函数connect_nocancel里面，其中会对uap结构体中的内容进行检测，之后则是从uap里面获取所需的一些参数或者结构体。

首先是通过file_socket函数，从当前进程中获取对应fd值所对应在内核中的套接字结构体指针，之后再获取相关对象数据，并进入connectit函数。

由于之前已经获取到了对应的socket结构体指针，所以在一进入connectit函数后，则会对当前socket加上一个全局的锁，通过socket_lock的调用施加一个锁，然后调用soconnectlock函数，返回后并根据设置判断是否是阻塞还是非阻塞的套接字，最终完成后则解锁返回。

在进入soconnectlock函数后，可以很快发现存在一个函数指针的调用 (*so->so_proto->pr_usrreqs->pru_connect)；对应的指针则是从当前套接字结构体中所获取的。

下面拿TCP协议来举例，在内核中，会定义一个名为tcp_usrreqs的结构体，其中保存了很多的协议实现的接口函数指针，包括前面所提到的pru_connect函数指针亦是存在，对应的则是tcp_usr_connect函数。

之后则是将tcp_usrreqs结构体指针保存在一个名为static struct protosw inetsw[]的结构体中。此处又保存了相关的初始化或者报文处理函数，以及一些配置函数，例如setsockopt函数进入后对TCP部分的配置实现则是在tcp_ctloutput中。

简单的路径跟踪之后，可以发现，在进入到具体对应的协议实现之前，则会有各种相关的检测，且在进入对应协议的接口之前，就已经调用socket_lock函数对当前的套接字进行加锁处理。

该漏洞是位于控制块在初始化阶段发生的，在初始化的时候，会通过相关函数对应当前套接字生成一个对应的FlowDivert协议下的控制块结构对象，并保存到相关的group组里面与当前的套接字对象上。

根据上述代码的更新情况可以总结出以下变化：

1. 函数进入之后，会根据传入的两个参数计算出一个group_unit；

2. 在insert之前保存参数和标志位，当函数触发error错误返回的时候，则会在分支置空 so_fd_pcb 和 SOF_FLOW_DIVERT标志位。

变化一：

flow_divert_derive_kernel_control_unit是根据传入的参数来计算一个在GROUP_COUNT_MAX(32)范围内的值，并返回。

返回的结果是作为group_unit变量，同步存放在套接字结构体中control_group_unit变量中，而后续则是通过group_unit的值来指明具体的group用于存放当前创建的控制块结构体指针fd_cb。

但是对漏洞缓解来看并无太大作用，可以确定不是导致漏洞产生的原因，只是在代码更新阶段同步引入了另外的功能。

变化二：

而在原代码中可以很轻易的发现存在如下代码：

此处的代码则是用于检测当进入该函数的时候，是否已经存在SOF_FLOW_DIVERT标志位，如若存在则会直接返回EALREADY错误值。

而在insert之前会对套接字设置SOF_FLOW_DIVERT标志位，在insert触发error之后则会清空SOF_FLOW_DIVERT标志位，由此可以猜测此处存在一个条件竞争的漏洞，而SOF_FLOW_DIVERT的处理则会用于限制另一个线程在同时间进入到此函数造成竞争漏洞的出现。

在进入分析之前，我们对相关函数进行了简单的跟踪，当时提到过一点，则是在进入对应接口具体实现之前，则已经会对当前套接字进行了一个加锁的处理，其中使用了socket_lock函数。

但是在flow_divert_pcb_insert函数中，可以发现，使用了socket_unlock函数进行暂时性的解锁，之后虽然又将锁加了回去，但是正因为此处的暂时性解锁，假如此时存在另一个线程请求加锁，则会处于阻塞状态，等待锁的释放，那么此处的暂时性解锁则会导致锁一释放的瞬间，另一个请求加锁的通行，则另一个线程则会进入下一步执行，而轮到flow_divert_pcb_insert函数会到socket_lock函数请求加锁而进入阻塞状态。

而在FlowDivert协议代码中，另外有一个函数flow_divert_detach，它通常是在close(socket)过程中进行的调用，相对于flow_divert_pcb_close()函数，此函数则会多出一个FDRELEASE引用计数释放的宏定义操作。往上根据函数引用可以发现，当进入sofreelastref函数后，若套接字存在SOF_FLOW_DIVERT标志位，则会进入flow_divert_detach函数。

但是如果是TCP协议的话，能调用到flow_divert_detach()方式则可以存在如下路径：

而上述路径，则可以不通过close(socket)即可触发，通过disconnectx(socket,0,0)则可以执行此路径，但是此路径只是理想状态下，具体如何才能执行到这条路径，下面继续分析。

在案例一的漏洞中，官方在新添加的代码中，调用flow_divert_pcb_insert函数之前，已经对相关的参数进行保存到了socket结构体中，尤其是SOF_FLOW_DIVERT的标志位的保存以及so_fd_pcb指针的保存。

若通过创建一个TCP套接字进入flow_divert_pcb_init_internal函数，而只有在insert成功之后，才会使用flow_divert_set_protosw函数通过g_flow_divert_in_protosw指针覆盖原套接字的so_proto指针。

那么，若是能够在so_proto指针被覆盖之前，调用到tcp_close函数，最终则会执行到flow_divert_detach函数。

1. 首先线程1当发生暂时性解锁的时候，会发生在flow_divert_pcb_insert函数中，

1. socket套接字具有SOF_FLOW_DIVERT标志位；

2. so->so_proto未曾覆盖，依旧使用的原TCP协议对应的接口函数；

3. 新创建的控制块对象已经保存于socket结构体中。

   
   

2. 线程2可以通过调用disconnectx(socket,0,0)

1. 由于采用的TCP协议接口函数，则会进入tcp_close函数，最终进入sofreelastref函数；

2. 线程满足SOF_FLOW_DIVERT标志位的条件，进入flow_divert_detach函数，且so→so_fd_pcb指针存在，会对so_fd_pcb指针进行引用计数释放操作。

   
   

3. 线程1在flow_divert_pcb_insert返回失败的时候，再一次调用FDRELEASE(fd_cb)，对fd_cb进行引用计数释放操作。

环环相扣，在线程1中fd_cb创建的时候，会默认引用计数增加一次，但是线程2在进入flow_divert_detach函数中，引用计数又会被释放，因此线程2中取出fd_cb对象，并对其进行释放回收处理，而线程1在flow_divert_pcb_insert函数返回失败的情况下，再次调用FDRELEASE释放fd_cb对象，而两者是从同一个套接字取出的fd_cb对象，对已经释放的对象进行操作，因此存在条件竞争导致的UAF的漏洞。

该漏洞是在新引入的功能分支代码中由于代码书写不规范而导致的，而在新引入的代码中，对于同一个进程，可以通过KernControl协议访问对应服务，并在当前进程的情况下，生成多个group组，对控制块进行管理。

在更新的macOS14 Sonoma系统后，XNU对于FlowDivert协议加入了新的功能实现，通过KernControl协议即可到达对应功能，另外实现了一条分支，可以注册的管理控制块的group数量可以达到到 (2^32 - 0x10000)数量级，用g_flow_divert_in_process_group_list链表进行管理，但是XNU这部分代码应该是不完善，仅仅能保存到用g_flow_divert_in_process_group_list链表管理的group中，而在使用的时候，依旧被限制在以前 GROUP_COUNT_MAX(32)的数量级中，大多只能访问 ID == (1 ~ 32)的group。

在新添加的代码中，有一段代码是用于新添加的group管理链表所对应的分支，在根据用户传入的ctl_unit变量用于查询对应符合条件的group对象时。

如果用户请求到达后，所传入的ctl_unit变量的值大于 FLOW_DIVERT_IN_PROCESS_UNIT_MIN(0xFFFF)，则会来到下面的分支，根据给定的ctl_unit数值，在双向链表中进行遍历匹配。

符合group_cursor->ctl_unit == ctl_unit情况下则会将指针group_cursor交给指针group 保存。

判断的时候，其实是分为group == NULL或者group ≠ NULL两种情况：

1. 如果group == NULL，则会直接跳出循环，返回的group为NULL；

2. 如果group ≠ NULL，则会从分支[2]和[3]再次进行选择，而正常符合情况的分支应该是从[3]走，对group指针附加引用计数，并最终返回一个带有引用计数的group指针；

3. 如果group ≠ NULL，同时满足分支[2]的条件，则会通过FDLOG函数打印一段日志，并直接跳出循环，但是没有对残留指针group进行处理，导致group返回的时候[4]返回的为不带有引用计数的group指针。

   
   

而能用户可控的分支则是满足如下条件即可：

内核会从当前所对应的fd_cb控制块指针保存的套接字获取对应的最近一次使用该套接字的进程的PID值。

函数so_update_last_owner_locked可以用来更新当前套接字对应的pid，很容易就能发现若是当前进程的pid与套接字所对应的套接字是不匹配的，就会更新为当前进程的pid保存到套接字结构体中。

最终可以发现可以很多网络协议所用的接口函数，例如accept、connect、bind、listen等函数都会在还没有进入具体的对应协议的API接口函数之前，就已经有此函数的调用。

macOS上通过fork进程即可传递让子进程继承使用父进程创建的套接字，所以fork函数创建子进程后，在子进程中调用listen函数，传入父进程创建的fd的即可。

iOS上触发，则可以通过共享文件，通过两个App绑定到共同可访问的文件，使用SCM_RIGHTS方法将套接字发送给另一个App，因为iOS中每个App都是以单进程出现，所以发送到另一个App，即可在另一个App上更新套接字中的进程ID。

在FlowDivert模块内，根据服务名，交叉引用即可发现如上代码，设置了FlowDivert服务对应的KernControl协议下的相关网络协议API接口函数，flow_divert_kctl_setup函数则是之前所提到的Apple新添加功能的主要内容之一，扩大了可供管理控制块的group数量级。

每一个连接到FlowDivert服务的客户端，则可以对应在内核中生成一个group对象，而其中用于指明group位置的则是通过connect过程中所传入的sc_unit变量作为特征，在之后查询的时候，会与查询时传入的参数进行匹配，匹配成功则会返回对应的group对象。

当然，在通过send函数可以发送自定义字段的数据报文，在flow_divert_input函数中进行解析。

当所传入的数据包类型为FLOW_DIVERT_PKT_CONNECT_RESULT时，则会进入flow_divert_handle_connect_result函数。

在XNU的某版本更新中，可以发现此函数是由socket_lock(so, 0)变更为socket_lock(so, 1)；而此处的套接字指针so又是从当前group中保存的其中一个fd_cb结构体中获取的，也是首次获取，因此此处属于第一次对该套接字加锁。

在tcp_lock()函数中，可以发现refcount参数的使用是用于对当前套接字的持有的引用计数增加，用于表明当前的套接字是被持有状态，而在刚才flow_divert_handle_connect_result函数中，首次获取套接字想要使用的时候，传入的参数2却为0，因此有个问题则是当前系统无法通过引用计数来判断当前套接字是否被持有。

当然，套接字是处于加锁状态，正常使用正常释放，处于使用状态用户是没有办法通过close函数，对其进行关闭回收的。

在flow_divert_handle_connect_result函数中，会有一个分支会调用到flow_divert_disable函数，此函数可以知道是用于关闭FlowDivert相关功能的实现，其中会对控制块的释放，标志位的清除，以及通过pffindproto函数 还原该套接字原协议的接口函数。

那么后续(*so->so_proto->pr_usrreqs->pru_connect)函数的调用，则会调用到原协议的connect函数，此处若原协议为TCP4协议，那么转到TCP4协议对应的connect函数中。

很明显，此处同样存在一个暂时性解锁，那么可以总结出以下三点：

1. 进入flow_divert_handle_connect_result函数，通过控制块fd_cb对象，加锁套接字，但是持有的引用计数未+1；

2. 在解锁之前，调用了flow_divert_disable函数，还原到原协议接口函数；

3. 其中会调用原协议接口函数，例如tcp_connect函数，其中存在socket_unlock函数对套接字暂时性解锁，那么此时的套接字引用计数不变，且不曾处于加锁状态。

   
   

那么即可通过close函数对套接字进行关闭，系统则会对套接字进行垃圾回收，当然close流程中，依旧存在各种检测，但是由于此时是通过fd_cb控制块取出的套接字，并不是通过常规的路径对文件描述符进行操控的，所以可以缺少对文件描述符使用过程中的各种检测的施加。

本文根据近年在FlowDivert模块中出现的历史漏洞分析，主要从四个漏洞入手进行分析：

第一个案例的漏洞产生是由于条件竞争且标志位设置的缺失，导致能够多个线程同时进入同一个路径调用同一个函数。

第二个案例的漏洞是在第一个案例的漏洞patch上进一步挖掘得到，发现的另一路径的条件竞争。官方在修复方案中，并没有对其具体的root cause进行彻底的根除，导致修复了仅仅修复了同时进入该函数导致的一种情况，但是暂时性解锁的问题却没有解决，因此产生了第二个案例的漏洞。

第三个案例的漏洞是由于开发过程中的小细节，对残留变量没有处理好，导致返回指针是一个残留指针，而残留指针是处于未添加引用计数的状态，由此产生后续的UAF漏洞。

第四个案例的漏洞是在当前模块另一个方面进行考虑，前面的漏洞都是在控制块相关的进行考虑，而第四个案例的漏洞则是从group的解析入手，发现属于被动取出套接字进行使用的时候，没有严格按照主动使用套接字相关接口的方法进行合理的使用。

总结上述此类漏洞产生的原因，从业人员在日常的研究工作中，可以针对审计产品新添加的功能或者从历史漏洞的patch入手，可能会有意想不到的正收益效果。