CVE-2023-37281 - Out-of-Bounds Read in Contiki-NG’s IPv6 Header Decompression

Contiki-NG is a popular open-source operating system designed for Internet-of-Things (IoT) devices. It’s widely used for sensor networks and smart devices because it’s lightweight and highly adaptable. But, just like anything connected to a network, it isn’t immune to security vulnerabilities. In this long read, we’ll break down a significant bug—CVE-2023-37281—which exposes Contiki-NG to memory safety bugs when handling incoming IPv6 packets.

What Is CVE-2023-37281?

CVE-2023-37281 is a security vulnerability found in Contiki-NG version 4.9 and prior. It affects how the operating system decompresses IPv6 headers, specifically during the processing of the IPHC (IPv6 Header Compression) feature.

The issue? The system checks that the packet contains enough data for various fields, but misses a crucial check for IPv6 addresses. This oversight can allow up to 16 bytes to be read out of the intended memory bounds—a classic "out-of-bounds read."

If a crafted packet is sent to a vulnerable Contiki-NG device, an attacker could read sensitive memory content, possibly leading to information leaks or other, more complex attacks.

Where Is The Bug?

The root of the issue is in the way IPv6 addresses are decompressed. Here’s the problematic code, simplified for clarity:

// Vulnerable code in contiki-ng/os/net/ipv6/uip6.c

// ...previous code...
memcpy(&ipaddr->u8[16 - postcount], iphc_ptr, postcount);
// ...following code...

iphc_ptr points to the incoming data buffer.

- postcount is calculated based on how much of the address needs to be "read" (the rest is filled in from a default, source, or other compressed value).
- There is no check to see if there actually is enough data in the buffer for postcount bytes before this memcpy occurs.

That’s a classic recipe for reading memory you shouldn’t! The attacker can basically say, “Hey, decompress an address, I promise this many bytes are coming!”—and if there aren’t, out-of-bounds memory gets read.

Exploit Scenario

Let’s say you have a device running Contiki-NG, maybe a smart meter or sensor, connected to an IPv6 network. An attacker sniffs the network and learns the link-local addresses in use. They then send a specially compressed IPv6 packet to your device with a header that triggers the buggy code path.

With careful control of the IPHC options (by manipulating address compression bits), the attacker can make postcount any value between and 16. If the packet buffer is too small for this, the system tries to copy in non-existent memory.

This doesn’t let the attacker directly change, execute, or control memory (not “remote code execution”) but leaks memory data. For an attacker, that could mean learning about device secrets, keys, stack layout, or random bytes which could help in later attacks.

Here’s a high-level idea of how an attacker could craft a packet to trigger the bug

import socket

# Replace these with your test device's address.
TARGET_IPV6_ADDRESS = "fe80::xxxx"
PORT = 12345  # Typical UDP port IoT app uses

# Create an IPv6 UDP socket
sock = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)

# IPHC-compressed header with bogus postcount > actual data
malicious_packet = b''

# Prepare your compressed IPv6 header: Set address compression bits 
# so postcount is, say, 12, but provide only 4 real bytes.
iphc_header = b'\xXX'  # carefully constructed per RFC 6282

malicious_packet += iphc_header
malicious_packet += b'\x01\x02\x03\x04'   # Not enough data!

# Send packet to target
sock.sendto(malicious_packet, (TARGET_IPV6_ADDRESS, PORT))

This Python snippet is schematic—real packets would need to comply with IPv6 and IPHC compression formats. But the logic is clear: “declare” a larger decompressed address than you actually send, and watch as the device reads memory it shouldn’t while processing your packet.

1. No Official Patch (As of June 2024)

A fixed release has not been made official. All versions up to and including 4.9 are vulnerable.

2. Apply the Unofficial Patch

You can manually patch your Contiki-NG distribution with Pull Request #2509. This fix essentially adds a check to make sure there’s enough buffer space before performing the memcpy.

Find the affected code and insert a check like

if(iphc_ptr + postcount <= packet_buffer_end) { // only copy if enough data
  memcpy(&ipaddr->u8[16 - postcount], iphc_ptr, postcount);
} else {
  // Handle error: Drop packet or raise alert
}

Alternatively, follow the diff in PR #2509 for the proper fix.

References and Further Reading

- Official GitHub Advisory
- Pull Request #2509: Security fix (check available buffer before memcpy)
- RFC 6282: Compression Format for IPv6 Datagrams in 6LoWPAN Networks
- NIST CVE Listing: CVE-2023-37281

Patch immediately with the PR #2509 fix, or isolate exposed systems.

- Limit network exposure; consider filtering packets at the border of your network to block suspicious or malformed IPv6 traffic.

CVE-2023-37281 underscores that even tiny systems need big security attention!


> *The above content is original and built exclusively for this post, aiming for clarity and practical guidance. Always test patches in a controlled environment before deploying them to your production fleet.*

Timeline

Published on: 09/15/2023 20:15:08 UTC
Last modified on: 09/19/2023 15:14:11 UTC