【蓝牙】CVE-2018-9357 BNEP_Write越界写导致RCE
补丁
https://android.googlesource.com/platform/system/bt/+/9164ee1aaf3609b4771d39302e3af649f44c9e66
这个漏洞我本来想先自己分析出来,但是没有找到漏洞点
我们先来看漏洞函数,这个函数是用于在BNEP连接里传输数据,所以我们需要先进行BNEP连接,一次BNEP连接,在处理数据包的时候,如果传入的是包指定了协议BNEP_802_1_P_PROTOCOL,就会触发漏洞
/*******************************************************************************
*
* Function BNEP_Write
*
* Description This function sends data over a BNEP connection
*
* Parameters: handle - handle of the connection to write
* p_dest_addr - BD_ADDR/Ethernet addr of the destination
* p_data - pointer to data start
* protocol - protocol type of the packet
* p_src_addr - (optional) BD_ADDR/ethernet address of the
* source
* (should be NULL if it is local BD Addr)
* fw_ext_present - forwarded extensions present
*
* Returns: BNEP_WRONG_HANDLE - if passed handle is not valid
* BNEP_MTU_EXCEDED - If the data length is greater than
* the MTU
* BNEP_IGNORE_CMD - If the packet is filtered out
* BNEP_Q_SIZE_EXCEEDED - If the Tx Q is full
* BNEP_NO_RESOURCES - If not able to allocate a buffer
* BNEP_SUCCESS - If written successfully
*
******************************************************************************/
tBNEP_RESULT BNEP_Write(uint16_t handle, const RawAddress& p_dest_addr,
uint8_t* p_data, uint16_t len, uint16_t protocol,
const RawAddress* p_src_addr, bool fw_ext_present) {
tBNEP_CONN* p_bcb;
uint8_t* p;
// MTU检查
/* Check MTU size. Consider the possibility of having extension headers */
if (len > BNEP_MTU_SIZE) {
BNEP_TRACE_ERROR("BNEP_Write() length %d exceeded MTU %d", len, BNEP_MTU_SIZE);
return (BNEP_MTU_EXCEDED);
}
// handle检查
if ((!handle) || (handle > BNEP_MAX_CONNECTIONS)) return (BNEP_WRONG_HANDLE);
p_bcb = &(bnep_cb.bcb[handle - 1]); // 获取p_pcb
/* Check if the packet should be filtered out */
if (bnep_is_packet_allowed(p_bcb, p_dest_addr, protocol, fw_ext_present, p_data) != BNEP_SUCCESS) {
/*
** If packet is filtered and ext headers are present
** drop the data and forward the ext headers
*/
if (fw_ext_present) {
uint8_t ext, length;
uint16_t org_len, new_len;
/* parse the extension headers and findout the new packet len */
org_len = len; // org_len表示Buffer原本长度
new_len = 0; // new_len表示新的Buffer长度
p = p_data; // p表示Buffer原始起始地址
do {
ext = *p_data++; // 获取第一个字节作为ext
length = *p_data++; // 获取第二个字节作为length
p_data += length; // 移动p_data指向下一个扩展起始地址
new_len += (length + 2); // new_length加上ext,length两字节,再加上length长度的数据
if (new_len > org_len) return BNEP_IGNORE_CMD; // new_len不能超过原始Buffer整体长度org_len
} while (ext & 0x80);
if (protocol != BNEP_802_1_P_PROTOCOL)
protocol = 0;
else {
// new_len加上4
new_len += 4;
p_data[2] = 0;
p_data[3] = 0;
}
len = new_len; // len为最终的新Buffer长度
p_data = p; // p_data重新指向Buffer起始
} else
return BNEP_IGNORE_CMD;
}
...
}通过阅读POC,如下构造数据包,传入BNEP()的p_data就是ext_1开始往后的数据
第一轮循环:
ext为0x81,表示还有一个ext,length为0x00,这样一轮循环后,p_data就指向了ext_2,new_len为2第二轮循环:
ext为0x00,表示后面没有ext了,length为0x00,第二轮循环结束后,p_data指向OOB
出了循环,指定protocol为0x8100也就是BNEP_802_1_P_PROTOCOL,就可以进入else分支,new_len加上4我没有理解在计算什么,后面直接对p_data[2]和p_data[3]进行赋值操作,此时完全没有判断OOB[0]开始往后4个字节属于Buffer边界内,这就是一个越界写漏洞
| ext(1) | dst_addr(6) | src_addr(6) | Protocol(2) | ext_1(1) | Len_1(1) | ext_2(1) | Len_2(1) | OOB[0] | OOB[1] | OOB[2] | OOB[3] | | - | - | - | - | - | - | - | - | - | - | - | - | - | - | | 0x80 | | | 0x8100 | 0x81 | 0x00 | 0x00 | 0x00 | | |||||
构造关键数据包的步骤如下
那么我们现在来看完整的攻击流程,第一步是建立BNEP连接,BNEP包格式如下,E为扩展标志位

BNEP Packet Type有如下几种类型,我们选择BNEP_GENERAL_ETHERNET
0x00
BNEP_GENERAL_ETHERNET
0x01
BNEP_CONTROL
0x02
BNEP_COMPRESSED_ETHERNET
0x03
BNEP_COMPRESSED_ETHERNET_SOURCE_ONLY
0x04
BNEP_COMPRESSED_ETHERNET_DEST_ONLY
0x05 - 0x7E
Reserved for future use
0x7F
Reserved for 802.2 LLC Packets for IEEE 802.15.1 WG
BNEP Control Type设置的是BNEP_SETUP_CONNECTION_REQUEST_MSG,此处不添加扩展数据
整个连接请求包的格式

其中Destination Service UUID和Source Service UUID长度不固定,最少是2个字节
Destination Service UUID: Size: 2-16 Bytes
0xXX
Depending on the UUID Size parameter, this is a 2-16 byte field containing the destination (service which the source device is connecting to) SDP service UUIDs [8]. Note: The size of both the destination and source service UUID SHALL be the same.
Source Service UUID: Size: 2-16 Bytes
0xXX
Depending on the UUID Size parameter, this is a 2-16 byte field containing the source (the service that the source device is using for the BNEP connection) SDP service UUIDs [8]. Note: The size of both the destination and source service UUID SHALL be the same.
BNEP_SETUP_CONNECTION_REQUEST_MSG包的构造过程如下
设置filter
Last updated