uIP Project uIP 1.0

An issue was discovered in uIP 1.0, as used in Contiki 3.0 and other products. The code that reassembles fragmented packets fails to properly validate the total length of an incoming packet specified in its IP header, as well as the fragmentation offset value specified in the IP header. By crafting a packet with specific values of the IP header length and the fragmentation offset, attackers can write into the .bss section of the program (past the statically allocated buffer that is used for storing the fragmented data) and cause a denial of service in uip_reass() in uip.c, or possibly execute arbitrary code on some target architectures.

An issue was discovered in uIP 1.0, as used in Contiki 3.0 and other products. The code that parses incoming DNS packets does not validate that the incoming DNS replies match outgoing DNS queries in newdata() in resolv.c. Also, arbitrary DNS replies are parsed if there was any outgoing DNS query with a transaction ID that matches the transaction ID of an incoming reply. Provided that the default DNS cache is quite small (only four records) and that the transaction ID has a very limited set of values that is quite easy to guess, this can lead to DNS cache poisoning.

An issue was discovered in uIP 1.0, as used in Contiki 3.0 and other products. The code that parses incoming DNS packets does not validate that domain names present in the DNS responses have '\0' termination. This results in errors when calculating the offset of the pointer that jumps over domain name bytes in DNS response packets when a name lacks this termination, and eventually leads to dereferencing the pointer at an invalid/arbitrary address, within newdata() and parse_name() in resolv.c.