国外安全研究人员近日曝光最新版Mac OSX 10.10.1系统上存在多处本地提权漏洞，由于提交到苹果官方时间太久都过未得到明确答复，导致研究者直接公布漏洞细节以及利用代码。

　　基于之前已发现的问题启发，我们又对Mac OS X上最新的 IOBluetoothHCIController服务进行了一些测试，功夫不负有心人，我们又发现了5个安全问题。这些问题已经在苹果公司的安全报告平台上报告过，但由于苹果官方过长时间未给予明确答复，所以我们公布了其中的4个漏洞的细节和PoC（另外一个苹果公司还在审查中）。这5个问题都出现在"IOBluetoothHCIController"上，可在IOBluetoothFamily内核扩展中应用（md5e4123caff1b90b81d52d43f9c47fec8f）。

　　问题1

　　许多由"IOBluetoothHCIController" 处理的回调函数不经检查就盲目的解引用指针参数。这些回调函数的调用者"IOBluetoothHCIUserClient：：SimpleDispatchWL()"可以通过空指针致使其最终被解引用。

　　具体的说就是，"SimpleDispatchWL() "处理的每一个user-space参数都包含一个数值和大小字段。当一个user-space客户端对一个NULL指针的参数提供了一个很大的值时，就会导致"IOMalloc(size)"调用失败，然后返回到空指针，最终导致空指针解引用。

　　针对"ispatchHCICreateConnection()"的方法我们提供了PoC，但是使用其他的调用函数又会使内核死机（通常其他的调用函数会接收多个指标参数）。首先我们排除了这个漏洞仅仅是一个本地DoS。然而Yosemite只能部分阻止从用户空间向NULL指针的映射，因此仍然有可能利用解除的空指标发动本地提权攻击，下面是部分代码：

　　问题2

　　由于一个bcopy（src， dest， strlen(src)）的调用（src完全由攻击者掌控），"IOBluetoothHCIController：：BluetoothHCIChangeLocalName()"受以前的缓冲区溢出漏洞影响。因现存的Canary栈堆的保护，该漏洞不可能被直接利用。但是，如果它和内存泄露漏洞结合使用的话，仍然可以发动本地提权攻击。

　　问题3：

　　"IOBluetoothHCIController：：TransferACLPacketToHW()"被作为一个输入参数来接收一个指针指向"IOMemoryDescriptor"。经过仔细检查发现该函数所提供的指针是非空的。然而，不论这次测试的结果如何，这个指针仍然会被解引用。（如下图所示，攻击者将输入参数存储在寄存器的r15中）当调用"DispatchHCISendRawACLData()"并使用构造函数"IOMemoryDescriptor：：withAddress()"来创建"IOMemoryDescriptor"时，由于该构造函数包含一个用户控制值，可能会导致失败并返回一个空的指针。该空指针如何利用在问题1中有过说明。

　　问题4：

　　该问题是由于对以下函数中的参数没有进行完整清晰的检查所造成的：

　　第一个参数req_index被用来在人机交互请求的队列中查找某人机交互请求（因此利用时需要用假请求填满该队列）。第二个整数参数"(num_of_keys)"被用来去计算其他输入的总大小，分别指向"p_device_addresses"和"p_bluetooth_keys"，如下图所示，这个值并没有在传到函数"IOBluetoothHCIController：：SendHCIRequestFormatted()"之前经过检查。原型如下：

　　传递的格式字符串"HbbNN"最终会将size_of_addresses由"p_device_addresses"倒序复制到outResultBuf，该指针将可以被攻击者控制的值在返回用户空间前进行重写和访问，因此我们可以在这里进行漏洞利用。

　　我们提供的PoC"lpe-issue1.c"可以利用这个Bug调用位于控制器0×4141414142424242地址的一个函数。由于多个vtable指针是损坏的，所以如果想要它清晰的返回user-space可能需要对Poc进行多次调试。（我们所采用的Poc都并不包含真正的负载，我们也并没有试图绕过Yosemite现有的安全功能。）

　　总结

　　随着最后一个问题被确认，我们将依据我们所发现的问题与苹果公司分享关于Kxet的一些结论，我们推测仍然有许多其他的导致崩溃问题或者本地提权漏洞存在。我们只是通过业余的时间进行了一次很好的分析，考虑到我们所付出的努力程度，我们认为应该对Kext代码进行一次完整的安全评估。