Twenty Year Anniversary

Broadcom TCP KeepAlive Offloading DoS / Out-Of-Bounds Read

Broadcom TCP KeepAlive Offloading DoS / Out-Of-Bounds Read
Posted Sep 27, 2017
Authored by Google Security Research, laginimaineb

Broadcom suffers from denial of service and out-of-bounds read vulnerabilities in TCP KeepAlive Offloading.

tags | advisory, denial of service, tcp, vulnerability
advisories | CVE-2017-7066
MD5 | 879a8ac244f3f3230f4a9c7db76d35f4

Broadcom TCP KeepAlive Offloading DoS / Out-Of-Bounds Read

Change Mirror Download
Broadcom: Denial of service and OOB read in TCP KeepAlive Offloading 

CVE-2017-7066


Broadcom produces Wi-Fi HardMAC SoCs which are used to handle the PHY and MAC layer processing. These chips are present in both mobile devices and Wi-Fi routers, and are capable of handling many Wi-Fi related events without delegating to the host OS.

In order to reduce overhead on the host, some Broadcom Wi-Fi chips support TCP ACK Offloading. When this feature is enabled, the firmware keeps a list of active TCP connections, including the 4-tuple, the SEQ/ACK numbers, etc.

Before performing the offloading operation, incoming TCP packets are verified to ensure they are valid. During this verification process, the incoming packets' checksums are calculated. For IPv4 packets, the IPv4 header checksum and TCP/IPv4 checksum are calculated and compared to the checksums in the incoming packet.

On the BCM4355C0 SoC with firmware version 9.44.78.27.0.1.56, the offloading verification is performed in RAM function 0x1800C8. Here is a snippet of the approximate high-level logic for this function:

int function_1800C8(void* ctx, void* packet) {

char* packet_data = *((char**)(packet + 8));
unsigned short packet_length = *((unsigned short*)(packet + 12));
char* packet_end = packet_data + packet_length;

//Getting the ethertype. If there's a SNAP header, get the ethertype from SNAP.
...

//Is this IPv4?
if (ethertype == 0x800) {

unsigned ip_header_length = (ip_header[0] & 0xF) * 4; //IHL * 4
char* tcp_header = ip_header + ip_header_length;

if (tcp_header > packet_end)
return 0;

//Make sure this is TCP
if (ip_header[9] != 6) //IPv4->Protocol == TCP
return 0;

//Making sure the IP total length is valid
unsigned short ip_total_length = (ip_header[2] << 8) | ip_header[3];
unsigned tcp_length = ip_total_length - ip_header_length;
if (tcp_header + tcp_length > packet_end)
return 0;

//Verify IPv4 checksum
unsigned short ipv4_checksum = *((unsigned short*)(ip_header+10));
if (ipv4_checksum != do_ipv4_checksum(ip_header, ip_header_length))
return 0;

//Verify TCP/IPv4 checksum
unsigned short tcp_checksum = *((unsigned short*)(tcp_header+16));
if (tcp_checksum != do_tcp_ipv4_checksum(ip_header, tcp_header, tcp_length))
return 0;

...
}
...
}

unsigned short do_ipv4_checksum(char* ip, unsigned len) {
...
return internal_calculate_ipv4_checksum(..., ip + 12, len - 12);
}

unsigned short do_tcp_ipv4_checksum(char* ip, char* tcp, unsigned len) {
...
return internal_calculate_tcp_ipv4_checksum(..., ip + 18, len - 18);
}


As can be seen above, there are a few missing length verifications in the snippet above:

1. The IHL field in the IPv4 header is not verified against in minimal allowed value (5). This means an attacker can provide an intentionally small value, such as zero. Doing so will cause the following accesses to be performed OOB (such as checking the IP header's protocol field, calculating the IPv4 checksum, etc).

2. The IP total length field is also not verified. An attacker can choose the total length field such that ip_total_length == ip_header_length. By doing so, tcp_length will contain the value zero. However, as the unsigned value (tcp_length - 12) is used as the length field in the internal TCP/IPv4 checksum calculation, this will cause the internal checksum calculation loop (RAM function 0x16DBF6) to receive a very large length field - causing an data abort due to an illegal access which will therefore crash the firmware.

The bug can be addressed by validating that the IHL is not smaller than the minimal allowed value (5), and by ensuring that the IP total length field is large enough to contain the IPv4 and TCP headers.

This bug is subject to a 90 day disclosure deadline. After 90 days elapse
or a patch has been made broadly available, the bug report will become
visible to the public.




Found by: laginimaineb

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

Want To Donate?


Bitcoin: 18PFeCVLwpmaBuQqd5xAYZ8bZdvbyEWMmU

File Archive:

June 2018

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jun 1st
    14 Files
  • 2
    Jun 2nd
    1 Files
  • 3
    Jun 3rd
    3 Files
  • 4
    Jun 4th
    18 Files
  • 5
    Jun 5th
    21 Files
  • 6
    Jun 6th
    8 Files
  • 7
    Jun 7th
    16 Files
  • 8
    Jun 8th
    18 Files
  • 9
    Jun 9th
    5 Files
  • 10
    Jun 10th
    2 Files
  • 11
    Jun 11th
    21 Files
  • 12
    Jun 12th
    32 Files
  • 13
    Jun 13th
    15 Files
  • 14
    Jun 14th
    16 Files
  • 15
    Jun 15th
    4 Files
  • 16
    Jun 16th
    1 Files
  • 17
    Jun 17th
    2 Files
  • 18
    Jun 18th
    15 Files
  • 19
    Jun 19th
    15 Files
  • 20
    Jun 20th
    8 Files
  • 21
    Jun 21st
    0 Files
  • 22
    Jun 22nd
    0 Files
  • 23
    Jun 23rd
    0 Files
  • 24
    Jun 24th
    0 Files
  • 25
    Jun 25th
    0 Files
  • 26
    Jun 26th
    0 Files
  • 27
    Jun 27th
    0 Files
  • 28
    Jun 28th
    0 Files
  • 29
    Jun 29th
    0 Files
  • 30
    Jun 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2018 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close