Impact

RIOT-OS contains a network stack with the ability to process 6LoWPAN frames. An attacker can send a crafted frame to the device resulting in an integer underflow and out of bounds access in the packet buffer. Triggering the access at the right time will corrupt other packets or the allocator metadata. Corrupting a pointer will lead to denial of service.

Patches

No public patches are available.

Workarounds

• Disabling SRH in the network stack

For more information

If you have any questions or comments about this advisory:

• Open an issue in RIOT
• Email us at RIOT-security

Bug Details

If RPL with SRH is used the next hop is read from an array of addresses.
The index calculation is susceptible to an integer underflow (source):

    num_addr = (((rh->len * 8) - GNRC_RPL_SRH_PADDING(rh->pad_resv) -
                 (16 - GNRC_RPL_SRH_COMPRE(rh->compr))) /
                (16 - GNRC_RPL_SRH_COMPRI(rh->compr))) + 1;

If rh->len is zero the bug can be triggered and later cause an out of bounds access while the next routing address is fetched.
The next address to use is calculated based one current_pos without any additional bounds checks (source):

    current_address = &addr_vec[(current_pos - 1) * compri_addr_len];
    memcpy(&addr.u8[pref_elided], current_address, addr_len);

The out of bounds access manifests as follows:

1. Calculate current_address which is out of bounds from addr_vec
2. memcpy from current_address to addr
3. Some checks are preformed with addr
4. memcpy from addr to current_address

During step 3 a interrupt can occur and change the content of current_address.
Then step 4 overwrites current_address again destroying the new contents.
This can lead to corrupted pointers, resulting in a crash.