Skip to content

Latest commit

 

History

History
51 lines (46 loc) · 3.04 KB

File metadata and controls

51 lines (46 loc) · 3.04 KB

Buffer Overflow during IPHC receive

Summary

Improper validation of the size of incoming 6LoWPAN fragments can lead an overflow in the packet buffer.

Description

During reassembling of 6LoWPAN packets _rbuf_add is used to add incoming fragments to the buffer. In _rbuf_add the datagram_size is retrieved from the fragment source:

    datagram_size = sixlowpan_frag_datagram_size(pkt->data);

If it is the first fragment, datagram_size is used to create a new reassembly buffer in _rbuf_get:

    else if ((res = _rbuf_get(src, netif_hdr->src_l2addr_len,
                              dst, netif_hdr->dst_l2addr_len,
                              datagram_size, datagram_tag, page)) < 0) {

Afterwards the fragment size is checked to not exceed the datagram size. But this check doesn't consider the increased size due to header decompression source:

    if ((offset + frag_size) > entry.super->datagram_size) {

Later the 6LoWPAN fragment is decompressed into the reassembly buffer source:

    gnrc_sixlowpan_iphc_recv(pkt, entry.rbuf, 0);

For unfragmented packets gnrc_sixlowpan_iphc_recv reallocates the buffer to the proper size source:

    if ((rbuf == NULL) &&
        /* (rbuf == NULL) => forwarding is not affected by this */
        (gnrc_pktbuf_realloc_data(ipv6, uncomp_hdr_len + payload_len) != 0)) {

But for fragmented packets this is not the case and no additional check is performed. (Also: reallocation size should be payload_len + sizeof(ipv6_hdr_t) as payload_len already includes uncomp_hdr_len).

The buffer is now assumed to be large enough for the packet payload. But due to the uncompressed IPv6 header being larger than the 6LoWPAN header this is no longer true.
While copying the payload from the 6LoWPAN snippet to the IPv6 snippet an out of bounds write in the packet buffer occurs source:

    memcpy(((uint8_t *)ipv6->data) + uncomp_hdr_len,
           ((uint8_t *)sixlo->data) + payload_offset,
           sixlo->size - payload_offset);

Impact

  • An attacker can manipulate data on the packet buffer and thus corrupt other packets and the allocator metadata
  • Corrupting a pointer will easily lead to DoS
  • Carefully manipulating the allocator metadata gives an attacker the possibility to write data to arbitrary locations and potentially escalate to RCE

Potential fix

During decompression of a fragmented 6LoWPAN packet check that the datagram size is not exceeded.