Ripple20 Vulnerability

Vedere Labs Team (formerly CyberMDX) Assists JSOF Research Team In Disclosing 19 Vulnerabilities Found In the Treck Network Stack

 
 

CISA Advisory (ICSA-20-168-01)

 

Summary

On June 16th, 2020, nineteen vulnerabilities affecting Treck‘s TCP/IP (network) stack were publicly disclosed. This disclosure is the result of a lengthy research and investigation process undertaken by JSOF and assisted by other parties, including the medical device security experts of CyberMDX.

The Treck network stack is a software component used by a large variety of connected devices. The vulnerabilities were bundled together in the same advisory: ICSA-20-168-01.

 

Overview

The network stack is the software component responsible for handling the network communication of a device. The Treck TCP/IP stack was designed for task-specific embedded devices (not PCs or mobile devices) and enjoys popularity among IoT vendors.

The 19 CVEs included within the CISA Advisory have been collectively dubbed “Ripple20”. Each of these vulnerabilities pertains to a different component of Treck’s network stack — from IP to UDP, DHCP, ICMP, TCP, ARP, etc. — and exposes connected devices to potential compromise through flaws in the security design. If exploited, that compromise may take the form of Exposure of Sensitive Information, Remote Code Execution, Out-of-Bounds Write, Denial of Service, etc.

Across all 19 vulnerabilities contained in the Ripple20 bundle, the common thread uniting them — beyond their shared point of discovery and presence in Treck’s TCP/IP stack — is the fact that they can all be exploited by a malicious actor with minimal requirements and skill.

Below all 19 of the Ripple20 vulnerabilities are listed along with their CISA conferred CVSS (v3.1) severity assessments (scale 1-10):

*For a more detailed explanation of CVE-2020-11896, jump here.

 

Affected Devices

The Ripple20 vulnerabilities exist in a network stack implementation that many manufacturers chose to integrate into their IP-addressable devices. This stack is independent of an operating system, so it can be difficult to identify from the viewpoint of standard endpoint tracking tools or publicly broadcast device details. As such, assessing whether or not a given device is subject to these vulnerabilities may constitute a challenge. 

Indeed, even for device manufacturers and vendors it can be difficult to verify the vulnerability of their products. This is because the decision to integrate the Treck network stack into a device might not even have been made by the manufacturer, but by a third-party technology provider that may have used Treck’s TCP/IP stack in their own offering that was then embedded into the product in question.

For example this RJ-45 port from Digi has built-in Treck-based network processing capabilities that might be integrated in another device to enable network communication. For vendors to even know this would require them to not just maintain a list of all their suppliers and technology partners for the product, but to maintain a list of all those suppliers’ and partners’ suppliers and partners. For most manufacturers, that level of product and process document is far from standard operating procedure.

Advanced vulnerability and threat detection tools such as the CyberMDX solution can be used to profile devices and identify exposure on the basis network communication behavior patterns consistent with the Treck network stack.

The following products have already been confirmed vulnerable:

• Baxter infusion pumps in the Sigma series
• Some BBraun infusion pumps
• Some Schneider/APC UPS devices
• Some Digi network solutions
• Some HP printers
• Some Ricoh printers

Additionally, a range of devices from Intel, Caterpillar, Maxlinear, Rockwell, Sandia National Labs, and HCL Tech have been found to be affected.

It must be noted however that while JSOF, CyberMDX, and other researchers continue to investigate the scope of these vulnerabilities a complete accounting of the attack surface will remain elusive. While we wait for the industry as a whole to work through the details and gain a more accurate handle on Ripple20’s impact, you are advised to reach out directly to vendors of devices suspected to be vulnerable for clarification.

 

Patching

Despite having fully cooperated with the responsible disclosure process and having prepared a new version of its software (6.0.1.67) that fixes the security flaws on which Ripple20 is predicated, it must be noted that Treck cannot directly update your devices. Treck supplies vendors a development kit for them to use when they package network stacks for their products. Unless vendors use that kit to incorporate firmware updates into their products, those products cannot be “patched”. 

In some cases, vendors will design their products to automatically and remotely receive these patches. In other cases, user interaction will be required to trigger an update. In still other cases, the vendor will need to dispatch a technician to physically arrive on premise and install the patch. 

In all cases, user follow up is imperative. First to understand what is required, then to coordinate as needed with the vendor, and finally to see the process through to completion.

 

Mitigation

In the event that the vulnerability of a given device or product line is suspected but hasn’t been confirmed, or the vendor hasn’t incorporated the updated Treck software version into products either directly or through an installable patch, mitigation will be required.

There are a number of immediate actions that can and should be taken to mitigate this vulnerability. These include:

• Contacting the vendors of affected devices and arranging for firmware upgrades based on Treck network stack version 6.0.1.67 and up.
• Asking the following questions and, according to the relevant answers, applying the prescribed policies to your network firewalls / IDSs –
  Do your affected devices need IP tunneling?
  • If not, drop all incoming tunneled packets.
  • If yes, perhaps you can drop specific unnecessary tunneling methods such as IP-in-IP ? PIV6-in-IPV4?
  Do your affected devices make use of IPV6?
  • If not – drop all incoming IPV6 packets.
  • If yes – can you drop specific packets like IPv6 multicast? IPv6 routing headers?
• Dropping unused ICMP control messages such MTU Update and Address Mask updates
• Normalizing DNS through a secure recursive server or DNS inspection firewall
• Referring to the Suricata IDS detection signatures published here and cross reference against the traffic in your network environment – making sure to immediately upon detection terminate any associated workloads and initiate quarantine procedures for affected endpoints.

Since these policies could rarely but possibly impact the normal functioning of certain network devices, it is best to apply them only to the inbound communications of Treck-based devices and start from a permissive mode (logging violations instead of blocking them) before moving on to an enforcement capacity.

 

CVE-2020-11896 In Detail

CVE-2020-11896 has been assigned a rare max-severity score of 10 and in the estimation of CyberMDX’s network security experts is also the Ripple20 CVE most likely to be exploited in the world. Here we provide further explanation of CVE-2020-11896 in the hopes that it helps the relevant parties to better understand and protect against it.

The following explanation is distilled from a more comprehensive description provided by JSOF.

Definitions

What usually happens in network stacks

• Network packets are constructed and deconstructed in layers (e.g. Ethernet -> IPV4 -> UDP). When data is moved across the network in packets, the packets are “unpacked” layer by layer, with a different handler designated to peel back each successive layer and prepare the packet for the next handler.
• When a fragmented packet arrives, each fragment is stored in a separate memory location. Each fragment is given a reference to the next fragment and together they form a linked list. Fragments are managed in this manner until a very late stage in the handling process.
• The IPV4 handler is in charge of gathering and linking all those linked fragments. Once gathered, it passes them together with the packet’s total size evaluation to the next layer handler.

The flaws in Treck’s network stack

• The IPV4’s size evaluation considers 2 possibilities—
  • The IPV4 header mentions fragmentation, in which case the size is calculated by summing all fragments.
  • The IPV4 header does not mention fragmentation, in which case the size is taken from the first fragment only. (As the subsequent list items make clear, though this logic is clean and intuitive, it is not without its deficiencies.)
• The size evaluation of the IPV4 does not consider a case in which there might be 2 IPV4 layers in the same packet (e.g. in IP-in-IP) and the first one is fragmented but the second one is not. The handler of the first IPV4 layer will evaluate the size according to (1.a), which results in a valid evaluation, while the handler of the second IPV4 layer will falsely evaluate the size according to (1.b).
• The false evaluation described in (2) does not result in actual trimming of excess fragments, but rather just changes the size descriptor.
• Reassembling the scattered fragments to a contiguous memory buffer takes place later in the process as part of the UDP handler. When the case described in (2) is followed by a UDP layer (Ethernet -> IPV4 -> IPV4 -> UDP), the following inconsistencies occur— 
  • The allocated size for that contiguous buffer will reflect the false evaluation given by the previous IPV4 handler (smaller than required)
  • Data is copied to the allocated buffer from all fragments without proper boundary check.
• The result is an overflow exceeding the allocated buffer where other memory locations used for entirely other purposes are being overwritten by arbitrary data taken directly from the attacker’s packet’s payload.

 

FAQ

On the same packet, how can the first IPV4 layer be fragmented and the next one not be?

Consider the situation layer by layer from the inside out:

• Suppose the last layer is UDP holding a 2KB payload of voice data.
• Above it there is an IPV4 header, not fragmented, its payload contains the whole UDP.
• Above that is another IPV4 for tunneling.

If, during its journey in the tunnel) that packet was passing through a network with a MTU that required it to be fragmented, the fragmentation would occur only at that last layer — the second IPV4. While splitting the packet also effectively fragments the lower layers, they are not “aware” of that.

This is just one example of a scenario in which such packets can legitimately be found.

An attacker may craft such a packet and successfully deliver it regardless of whether a tunnel or 2 IPV4 headers are actually required for the packet to arrive.

 

Why do packet fragments get copied to a contiguous memory buffer only later in the handling process?

By design, this is how a “zero copy” implementation of a network stack should behave.

A zero copy software implementation performs no copying of data buffers while operating to achieve maximum efficiency. With regard to network stack implementation, this data buffer is usually the packet, which is usually called upon by locations in code.

 

How feasible is this attack?

Researchers from JSOF have developed a proof-of-concept that not only performs the described overflow but also uses it in order to remotely execute arbitrary code on a Digi Connect network device.

 

Wasn’t the vulnerability listed here as CVE-2020-11896 already published as CVE-2020-10136?

No, the description of CVEs 2020-10136 and 2020-11896 sound similar but are not at all related.

 

---

 

 

About JSOF 

JSOF is a team of experienced cyber security professionals, with a wide and deep understanding of software, technology, and security. Experts in both offensive and defensive security, JSOF brings a vast amount of experience and expertise to bear in fields including mobile, IOT, automotive, trusted computing, anti-IP protection, and embedded devices. To learn more, please visit JSOF’s website at www.jsof-tech.com.