Contiki-OS Contiki 3.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 Contiki Operating System 3.0. A use-after-free vulnerability exists in httpd-simple.c in cc26xx-web-demo httpd, where upon a connection close event, the http_state structure was not deallocated properly, resulting in a NULL pointer dereference in the output processing function. This resulted in a board crash, which can be used to perform denial of service.

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.

In Contiki 3.0, a buffer overflow in the Telnet service allows remote attackers to cause a denial of service because the ls command is mishandled when a directory has many files with long names.

In Contiki 3.0, a Telnet server that silently quits (before disconnection with clients) leads to connected clients entering an infinite loop and waiting forever, which may cause excessive CPU consumption.

In Contiki 3.0, Telnet option negotiation is mishandled. During negotiation between a server and a client, the server may fail to give the WILL/WONT or DO/DONT response for DO and WILL commands because of improper handling of exception condition, which leads to property violations and denial of service. Specifically, a server sometimes sends no response, because a fixed buffer space is available for all responses and that space may have been exhausted.

In Contiki 3.0, potential nonterminating acknowledgment loops exist in the Telnet service. When the negotiated options are already disabled, servers still respond to DONT and WONT requests with WONT or DONT commands, which may lead to infinite acknowledgment loops, denial of service, and excessive CPU consumption.

An issue was discovered in Contiki Operating System 3.0. A Persistent XSS vulnerability is present in the MQTT/IBM Cloud Config page (aka mqtt.html) of cc26xx-web-demo. The cc26xx-web-demo features a webserver that runs on a constrained device. That particular page allows a user to remotely configure that device's operation by sending HTTP POST requests. The vulnerability consists of improper input sanitisation of the text fields on the MQTT/IBM Cloud config page, allowing for JavaScript code injection.