1. Background
Recently, the JSOF research lab discovered a series of vulnerabilities on the Treck TCP/IP stack, which were dubbed Ripple20. Successful exploit of these vulnerabilities may allow remote code execution or disclosure of sensitive information. Technical details will be fully released at BlackHat USA 2020.
At present, it has proven that Ripple20 has reached critical Internet of Things (IoT) devices from a wide range of fields, involving a diverse group of vendors, such as HP, Schneider Electric, Intel, Rockwell Automation, Caterpillar, Baxter, as well as many other major international vendors suspected of being vulnerable in medical, aviation, transportation, home device, enterprise, energy (oil/gas), telecom, retail, and other industries.
2. Vulnerability and Analysis
2.1 Introduction to the Treck TCP/IP Stack
A high-performance embedded system is a key technology that drives fast-growing market innovations and high-growth applications. Since 1997, Treck has been committed to designing, distributing, and supporting Internet protocols for real-time embedded systems. The TCP/IP stack is a high-performance protocol stack designed for embedded systems and is widely applied to embedded devices and IoT devices.
Treck TCP/IP is designed to be high performing, scalable and configurable for easy integration into any environment regardless of processor, commercial RTOS, proprietary RTOS, or if no RTOS is being used. By designing API’s to interface the kernel, timer, driver, sockets the Treck TCP/IP provides easy integration into a wide variety of embedded products.
2.2 Analysis of the Treck TCP/IP Stack
Packets on the Treck TCP/IP stack are represented by a tsPacket structure. Each packet is associated with a data buffer which holds the raw data arriving from the interface driver. The tsPacket structure also holds another important structure called ttUserPacket and a pointer to a tsSharedData structure, which contains the information needed by Internet protocols to process packets.
A common pattern in the Treck TCP/IP stack is adjusting the pointer when it moves between layers in the stack. For example, if the packet is an ICMP echo request packet (ping), it will be composed of three layers: Ethernet, IPv4, and ICMP. In this case, when the Ethernet layer (in the tfEtherRecv function) is processed, the pointer points to the beginning of the Ethernet header and then is adjusted with the following code before moving to the next layer:
pkt->pktuLinkDataPtr = pkt->pktuLinkDataPtr + 0xe;pkt->pktuLinkDataLength = pkt->pktuLinkDataLength - 0xe;
pkt->pktuChainDataLength = pkt->pktuChainDataLength - 0xe;In this example, 0xe (14 in decimal) is the size of the Ethernet header (6 (destination MAC address) + 6 (source MAC address) + 2 (EtherType on the next layer)).
After tfEtherRecv finishes processing the packet, it uses the EtherType field that symbolizes the next-layer protocol to forward the packet to the next layer for processing. Supported EtherTypes include ARP, IPv4, and IPv6.
The tsUserPacket structure is displayed as follows:
The Treck TCP/IP stack handles the reassembly of fragments in tfIpReassemblePacket, which is called by tfIpReassemblePacket. Whenever IP fragments sent to devices are received, the procedure is called. If some fragments are missing, the function will return NULL. Otherwise, if all fragments arrive, the protocol stack will use the pktuLinkNextPtr field to link these fragments and pass on the packet to the next layer for processing. “Reassembly” here does not mean copying the packet to a contiguous memory block. Instead, it means linking the fragments in a linked list.
2.3 Cause of the Vulnerability
When the protocol stack processes outer fragments, it uses the pktuLinkNextPtr field in the tsUserPacket structure to link them. When the tfIpIncomingPacket function processes inner IP packets (protocol = 4), it processes incoming fragmented data (the inner packet is represented by two tsPacket structures linked together), but still calls the vulnerable flow.
The inner packet passes the IP header sanity checks, for only the pktuChainDataLength field of the tsUserPacket rather than pktuLinkDataLength is considered. The total length (32) of the inner IP packet is smaller than the length (1000 + 8 + 20 = 1028) of chain data. Therefore, the Treck TCP/IP stack will attempt to trim the packet by setting the pktuLinkDataLength field and the pktuChainDataLength field to the same value which is the total IP length (32 in the example). That is why the inner IP packet is represented by two tsPacket structures linked together. However, their total cusize is greater than the value of the pktuChainDataLength field (it is changed from 1028 bytes to 32 bytes after trimming).
The aforesaid example packet structure is shown in the following figure:
It an application is listening on any UDO port, a UDP packet destined for this port will be passed to the socket handling function tfSocketIncomingPacket and be added to the socket reception queue (later polled by the application layer later). In research, when the socket reception queue of the UDP packet is found to be non-empty and a new packet arrives, the flow containing heap overflows can be achieved.
In the test, the first packet link has a small buffer size. Here, sizeOfPacketBuffer is relatively small (on the order of 10s of bytes). But when the packet reaches this flow, pkt->pktuChainDataLength equals 4 (after trimming it was 32, then decremented by 20 (size of IP header) when processing the IP layer, and then decremented again by 8 (size of UDP header)). So 4*4=16 is less than sizeOfPacketBuffer, and it passes this check.
It is necessary to guarantee that the reception queue of the UDP packet is non-empty (otherwise, the flow is not reached). Sending many UDP packets to the same port fast enough would do the trick. Before we arrive at tfSocketIncomingPacket, which is where the overflow occurs, our vulnerable packet passes through tfUdpIncomingPacket. This function contains some sanity checks related to UDP. To avoid this, we should ensure that the UDP length field equals the pktuChainDataLength field minus the size of the inner IP header.
In a word, if a UDP port listens on an affected device, packets can be sent rapidly so that the socket reception queue is non-empty. Meanwhile, sending a fragmented UDP packet will trigger the vulnerability.
3. Security Recommendations
3.1 Device Vendors
Check code assets to find out whether relevant code of Treck has been used and the software is the affected version (earlier than 6.0.1.67) via source code.
As for binary library files, run the following command to check the versions of the library files and whether the affected versions have been used.
strings driver name | grep -e "[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}"Establish a security assessment process for the introduction of third-party databases.
3.2 Device Users
Prohibit IP_IN_IP access to IoT devices, which is similar to data access through a VPN.
If the protection device in use supports customization of rules, add the following rule:
#IP-in-IP tunnel with fragments
alert ip any any -> any any (msg:"VU#257161:CVE-2020-11896 Fragments inside IP-in-IP tunnel"; ip_proto:4; fragbits:M; rev:1;)Upgrade to the latest versions as soon as they are available on device vendors’ websites.
Restrict access privileges and scope of IoT devices.
3.3 Security Vendors
Add the following rule to protection products and associate it with device assets (whether IoT devices or not) to reduce false positives.
#IP-in-IP tunnel with fragments
alert ip any any -> any any (msg:"VU#257161:CVE-2020-11896 Fragments inside IP-in-IP tunnel"; ip_proto:4; fragbits:M; rev:1;)Detection Devices
At present, the following vendors are found to be affected by this vulnerability:
- Aruba Networks
- Baxter US
- B. Braun
- CareStream
- Caterpillar
- Cisco
- Digi International
- Green Hills Software
- Hewlett Packard Enterprise
- HP Inc.
- Rockwell Automation
- Schneider Electric
- Teradici
- Treck
- Xerox
- Zuken Elmic
Specific device models need to be further confirmed.
4. Product Solution
4.1 NTI Intelligence Association
NSFOCUS Threat Intelligence center (NTI) collected detailed information of the vulnerability immediately, including the cause of the vulnerability, affected product versions, and solution. The vulnerability CPE field contains machine-readable fields concerning the affected products and can be used by users to associate with the local asset management library to identify whether there exist affected devices.
4.2 IoT Access Gateway
NSFOCUS IoT Access Gateway can actively detect IoT devices to form an IoT device asset library land create attackers’ profiles by means of traffic analysis.
After being updated to include Treck vulnerability signatures, the device can actively detect IoT devices using the Treck TCP/IP stack and generate alerts to these devices.
