Digi International Security Notice
TRECK TCP/IP Stack "RIPPLE20"
VU#257161
ICS-VU-035787
June 16th, 2020
 
The following CVE’s have been assigned to these vulnerabilities:

Overview

A number of high level security vulnerabilities (tracked as vu#257161), nicknamed “RIPPLE20” was discovered by an independent security research company JSOF, with researchers Moshe Kol, and Shlomi Oberman. In working with the researchers, Digi was able to narrow down the vulnerabilities to a third party closed source library that provides TCP/IP network services, also known as the TRECK TCP/IP network stack. Under specific circumstances, it may be possible that these vulnerabilities could lead to a remote code execution via a network based attack without authentication. The purpose of this notice is to inform you of the vulnerability, how it affects Digi products, and the steps necessary to remediate this issue. In our review and testing of this vulnerability, we found that reproducing an attack that affected the confidentiality and integrity of a device was difficult. Attacking the availability of a device via a Denial of Service (DoS) attack can also be difficult, but much easier than a confidentiality and integrity attack. We have rated this vulnerability as a HIGH risk to our customers. Digi released firmware in April that addressed the above listed vulnerabilities, and this firmware is available on our website.
Affected Products

The security teams at Digi have evaluated the exposure of the vulnerability to Digi products and determined the overall risk to this vulnerability to our products is high. We have found that the listed products below are affected by this vulnerability. A number of the vulnerabilities could be remotely exploitable. The following products are impacted:
Product families:

• Connect SP
• Connect ME
• Connect ES
• Connect EM
• Connect WME
• Connect 9C
• Connect 9P
• ConnectPort X4 (all variants)
• ConnectPort X2 (NOT X2e)
• ConnectPort TS (Not LTS)
• AnywhereUSB (excluding Plus)
• NetSilicon 7520, 9210, 9215,9360, 9750
• Any embedded products using the NET+OS 7.X environments

Following best security practices, Digi recommends that all of its customers update their products to the new firmware versions (firmware versions release on the week of April 20^th, 2020).

 
Products Not Affected
The following Digi products and services are not affected by this vulnerability:

• Connect Products with 2MB flash are NOT affected, as they use a different TCP/IP stack
• ConnectPort X2e
• ConnectPort LTS
• AnywhereUSB PLUS
• Net+OS versions 6 and earlier
• WR11,WR21,WR31,WR44 products
• IX—products, EX—products
• All other Digi products not mentioned above.

Note: If you have any questions on any Digi products and services that are not listed please contact us  or via the web site at www.digi.com/support.

Detailed Information on Affected products

Background

The vulnerabilities started out as an analysis of the TCP/IP processing code that is part of the NET+OS software that Digi provides to embedded customers. The TRECK source code has been licensed by Digi International to include in the NET+OS build environment. Further, Digi International has also licensed the TRECK stack to use within its network products. In working with the researchers, they were able to demonstrate a remote code execution without any authentication on a Connect ME device. In reviewing the source code, it was apparent that a number of security checks were not completed in the TCP/IP stack. Although the proof of concept existed, the attack is very dependent on code positioning, within the product.
The TRECK Stack is found in a variety of embedded devices starting from the early 2000’s for that decade. There will be many vendors that are impacted by these library routines.

Analysis

The example exploit used a ROP (return oriented programming) to provide the remote code execution. The example exploit was tried on like hardware within Digi’s lab, but we were not able to reproduce the code exploit. Further, DoS testing was conducted as well, and we were not able to impact a device. However, although our tests were negative, it was very apparent that the attacks ARE possible, given enough time. Our internal Digi team did not prioritize spending much time for attacks, but instead focusing on the codebase to prevent the attacks, and put the proper check in place to protect our devices and customers. Due to the complexity of these attacks, the impact is difficult to determine and will vary between device type and even firmware versions. Because of this complexity, CVSS scoring can be different for each device, and has left up to the individual product companies to determine. In our analysis, and due to other protections such as stack protections etc.. we determined that the highest level attack was a CVSSv3.1 score of 8.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H)
Although some organizations may have this listed as a score of 10.0, we found that the attack was not considered “easy”, at least where integrity and confidentiality are impacted. We do believe that availability may be considered an easy attack for some devices, but in a recalculated score for ONLY availability would be a CVSS3.1 score of 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
 

Below is an overview of each issue (CVE) that was addressed

1. CVE-2020-11896 (Treck Issue ID 3620) Improper Handling of Length Parameter Inconsistency (CWE-130) in IPv4/UDP component.  An unauthorized network attacker can send a malicious packet that can be used to inject arbitrary code on the target system.
2. CVE-2020-11897 (Treck Issue ID 2735) Improper Handling of Length Parameter Inconsistency (CWE-130) in IPv6 component.  An unauthorized network attacker can send a malicious packet that can lead to out of bounds write on the target device.
3. CVE-2020-11898 (Treck Issue ID 3621) Improper Handling of Length Parameter Inconsistency (CWE-130) in IPv4/ICMPv4 component. An unauthorized network attacker can send a malicious request that can lead to unintended exposure of sensitive information on the target device.
4. CVE-2020-11899 (Treck Issue ID 3623) Improper Input Validation (CWE-20) in IPv6 component when handling a packet sent by an unauthorized network attacker.  An unauthorized network attacker can send a malicious request that can lead to out of bounds read on the target device.
5. CVE-2020-11900 (Treck Issue ID 3408) Double Free (CWE-415) in IPv4 tunneling component when handling a packet.  An unauthorized network attacker can use malicious packets that could lead to unexpected behavior of memory access that can be used to write or read values in arbitrary memory spaces.
6. CVE-2020-11901 (Treck Issue ID 3633) Improper Input Validation (CWE-20) in DNS resolver component when handling a packet sent.  An unauthorized network attacker can inject arbitrary code on the target system using a maliciously crafted packet.
7. CVE-2020-11902 (Treck Issue ID 3627) Improper Input Validation (CWE-20) in IPv6overIPv4 tunneling component.  An unauthorized network attacker can send a malicious packet that may expose data that is present outside the bounds of allocated memory.
8. CVE-2020-11903 (Treck Issue ID 2450) Out-of-bounds Read (CWE-125) in DHCP component when handling a packet.  A local network attacker can craft a malicious Layer-2 DHCP request that could lead to access of sensitive information on the destination device.
9. CVE-2020-11904 (Treck Issue ID 3624) Integer Overflow or Wraparound (CWE-190) in Memory Allocation component.  An unauthorized network attacker can send a malicious packet that may result in corruption of sensitive information, a crash, or code execution on the target device.
10. CVE-2020-11905 (Treck Issue ID 3628 and 3432) Possible Out-of-bounds Read (CWE-125) in DHCP component.  A local network attacker can send a malicious Layer-2 DHCP packet that could lead to an unintended exposure of sensitive information on the target device.
11. CVE-2020-11906 (Treck Issue ID 3625) Improper Input Validation (CWE-20) in Ethernet Link Layer component.  A local network attacker can send a malicious Layer-2 Ethernet packet that can cause trigger an integer underflow event leading to unexpected behavior of a crash or segmentation fault on the target device.
12. CVE-2020-11907 (Treck Issue ID 3637) Improper Handling of Length Parameter Inconsistency (CWE-130) in TCP component.  A remote attacker can send a malformed TCP packet that can cause trigger an integer underflow event leading to unexpected behavior of a crash or segmentation fault on the target device.
13. CVE-2020-11908 (Treck Issue ID 2450) Improper Null Termination (CWE-170) in DHCP component. A local network attacker can send a malicious Layer-2 DHCP packet that could lead to an unintended exposure of sensitive information on the target device.
14. CVE-2020-11909 (Treck Issue ID 3632) Improper Input Validation (CWE-20) in IPv4 component.  A remote attacker can send a malformed IPv4 packet that can cause trigger an integer underflow event leading to unexpected behavior of a crash or segmentation fault on the target device.
15. CVE-2020-11910 ((Treck Issue ID 3629) Improper Input Validation (CWE-20) in ICMPv4 component.  An unauthorized network attacker can send a malicious packet that may expose data that is present outside the bounds of allocated memory.
16. CVE-2020-11911 (Treck Issue ID 3631) Improper Access Control (CWE-284) in ICMPv4 component.  An unauthorized network attacker can send a malicious packet that can lead to higher privileges in permissions assignment for critical resources on the destination device.
17. CVE-2020-11912 (Treck Issue ID 3636) Improper Input Validation (CWE-20) in TCP component.  An unauthorized network attacker can send a malicious packet that may expose data that is present outside the bounds of allocated memory.
18. CVE-2020-11913 (Treck Issue ID 3634) Improper Input Validation (CWE-20) in IPv6 component.  An unauthorized network attacker can send a malicious packet that may expose data that is present outside the bounds of allocated memory.
19. CVE-2020-11914 (Treck Issue ID 3635) Improper Input Validation (CWE-20) in ARP component.  A local network attacker can send a malicious Layer-2 ARP packet that could lead to an unintended exposure of sensitive information on the target device.

Functions impacted:

• Potential internal overflow conditions eventually leading to a DoS offline or reboot failure
• Potential ability to run remote code send via network packets. This open the possibility that all functions could be impacted.

Risk

For generic risks of this vulnerability, we have classified the risk of RIPPLE20 to our products as HIGH. During our testing, we were not able to reproduce any remote exploits that this vulnerability has created. However, we understand that the exploits are possible, and it only is a matter of time and effort to produce them. Although MITRE may have rated this vulnerability in some cases the highest (CVSS of 10.0), the real threat with our devices, and the complexity of the attack, and such features as stack DEP and other on a number of devices reduces the severity to a HIGH, or CVSS score of 8.1

Risk of RIPPLE20 to our products and services are:

• The more likely scenario is that a device may reboot while under use and attack.
• If an attacker was extremely motivated and wanted to attack a specific device and firmware version, it could be possible for a device to run remote code sent to it via the network.

Risk needs to be determined by the end customer and how they have chosen to deploy the device within their environment. We make this determination based on the following criteria:

• Most customers have deployed the devices within a network that is not reachable from the Internet.
• The vulnerability is remotely exploitable, but would require a significant amount of work and understanding about the firmware version and device to lead to a remote code execution.
• IF we only consider a DoS attack only, for an IoT device in many cases this could be little or so significance if a device reboots. Getting a device to fail without a reboot would be much more difficult in the field due to watchdog timers and other hardware that we have implemented into our devices.

Suggested Steps to Protect Your Devices

To fix or mitigate devices affected by this vulnerability, we suggest the following steps.

Fixing Devices 

Update Firmware

The recommended fix for our devices is to update to a fixed Firmware version. Digi has released new firmware versions for all of the affected devices. You can also visit www.digi.com/support for more information specific to your device. We would also recommend subscribing to the RSS feed on the support site for your product to get immediate notice of any new firmware or document releases specific to your product.

Mitigation Steps

If a firmware update is not possible, mitigations would include network segmentation, or network restrictions to the device. It is also possible that a deep inspection packet firewall should be able to mitigate this, as all of the exploits are considered in some for an illegal network packet. The packets may be passed by routers/switches and even firewalls, but deep packet inspection firewalls that do reassembly and inspect for other packet irregularities should be able to stop these attacks. US-Cert is creating a list of potential network pattern rules to detect and potentially protect against these attacks. It is ultimately up to the customer to validate that all of these steps will mitigate against the vulnerability.
Some example suggested rules:

• Disable or block IP tunneling both IPV6 and IPv4 or IP-in-IP
• Block source routing
• Enforce TCP inspection and reject malformed TCP packets
• Block Unused ICMP control messages such as MTU update and address mask updates
• Normalize or block IP fragments if not supported in your environment.

Resources for RIPPLE20

If you are interested in learning more about the disclosure, please feel free to visit the web pages below:

• https://jsof-tech.com/ripple20
• https://www.kb.cert.org/vuls/id/257161
• https://www.wired.com/story/ripple20-iot-vulnerabilities/
• Email: ripple20@jsof-tech.com
• https://www.digi.com/security

Thanks:

• Moshe Kol and Shlomi Oberman from JSOF in working with Digi.
• TRECK for working with the researchers and working for a responsible disclosure process
• Vijay Sarvepalli from US-CERT Coordination center and Carnegie Mellon University

If you have any other questions regarding this vulnerability and how it affects Digi hardware products, feel free to contact security@digi.com