Take Down MacOS Bluetooth with Zero-click RCE Author: Jianjun Dai(@jioundai) of 360 Alpha Lab Zero-click vulnerabilities have become more and more popular in recent years, and the bounty for full exploit chains has also surged. In 2019, Apple Security Bounty even raised the reward up to one million US dollars for zero - click kernel code execution wi th persistence and kernel PAC bypass. In the meanwhile, high prices also mean greater threat the vulnerability may pose and more difficulty to discover. Anyone who has done researches on remote zero -click vulnerabilities knows that it is very tough to get a stable zero-click exploitation as it lacks flexible interface for remote calls and has many unstable factors. In December 2019, I submitted 5 macOS Bluetooth vulnerabilities to Apple, together with a complete report of zero -click bugs that can remotely t ake down macOS Bluetooth. The odd thing is that in the March security update, the vulnerability is numbered CVE -2019 -8853 (why it’s 2019?), and macOS Catalina 10.15.3 was left out of the affected versions. In this article, I will detail two vulnerabilities used in the exploit chain, CVE - 2020 -3847 and CVE -2020 -3848, and how did I get the code execution. However, I will not release the exploit code itself. If you are interested, you can try to reproduce the exploit yourself. 0x0 MacOS Bluetooth 0x01 Bluetooth Architecture In macOS, the data on the layer L2CAP (Logical Link Control and Adaptation Protocol) is processed by the kernel driver IOBluetoothFamily (the vulner ability I found in the IOBluetoothFamily was in Apple's January acknowledgement). The data on L2CAP, such as SDP, BNEP, and so on, are handled by the user mode process bluetoothd, and the bluetoothd process runs with root privilege. 0x02 SDP Frame The two vulnerabilities involved in this exploit are both in the processing code of SDP (Service Discovery Protocol) data frames. This section briefly introduces the SDP fram e, as follows: The first byte PDU field indicates the SDP request or response message. PDU = 2/4/6 indicates SDP Request, and PDU = 0/1/3/5 indicates SDP Response. The Parameter Length field indicates the length of the payload. You can use wireshark to capture and analyz e the packets as follows: 0x1 Vulnerability Details 0x11 CVE -2020 -3847 CVE-2020 -3847 can cause remote out -of-bounds read, and it exits in the (PDU=4) of function [SDPServerConnection handleServiceAttributeRequest:length:transactionID:]. To trigger the vulnerability, two SDP requets in different states should be sent. The 1st request: Line 136 cont_state reads a byte from the transmitted data packet (pdata). The first time we make cont_state = 0, so line 143 is_cont_pkt = false. Then move onto the following lines: Line 270, rem_len is an indirectly controllable variable. According to the data in the request packet, query the attributes in the SDP database, Rem_len indicates the length of the query, let’s assumed it to be 0x16. max_list_len is 2-byte data read from the data packet, and it is also a directly controllable variable. We can make rem_len> max_list_len so that the c ode goes to the else branch. Line 280, because is_cont_pkt = false, the final code is executed to line 284. rem_len will assign service_attr_result_len to a member variable of the object pSDPServerConn, and pSDPServerConn -> ServiceAttributeResults = malloc (0x16). The pSDPServerConn object is an object generated when an SDP socket connection is established. It is destroyed only when the connection is disconnected. The 2nd SDP Request: Send a second SDP request message. Make cont_state = 4, so that is_cont_p kt = true. Line 153, cont_offset is an unsigned int variable that reads 4 bytes of data from the data packet and is also directly controllable. Line 154, we make cont_offset> 0x16. Assuming cont_offset = 0x18, an integer overflow occurs and rem_