9.8 - VU#608209

Overview

HCC Embedded's software called InterNiche stack (NicheStack) and NicheLite, which provides TCP/IP networking capability to embedded systems, is impacted by multiple vulnerabilities. The Forescout and JFrog researchers who discovered this set of vulnerabilities have identified these as "INFRA:HALT"

Description

HCC Embedded acquired NicheStack from Interniche in order to provide TCP/IP protocol capabilities to lightweight devices such as IoT. NicheStack has been made available since late 1990's to a widely varied customer base in multiple forms to support various implementations. This has made NicheStack to be part of a complex supply chain into major industries including devices in critical infrastructure.

Forescout and JFrog researchers have identified 14 vulnerabilities related to network packet processing errors in NicheStack and NicheLite versions 4.3 released before 2021-05-28. Most of these vulnerabilities stem from improper memory management commonly seen in lightweight operating systems. Of these 14 vulnerabilities, five involve processing of TCP and ICMP (OSI Layer-4 protocols) and the rest involve common application protocols such as HTTP and DNS (OSI Layer-7). The processing of these OSI layers involve a number of boundary checks and some specific "application" processing capabilities (such as randomization) commonly overlooked in development of lightweight networking software.

Various stakeholders, including HCC Embedded, have made attempts to reach impacted vendors to provide software fixes that address these issues. A lack of formalization of software OEM relationships and a lack of Software Bill of Materials (SBOM) has complicated this outreach and the much-needed identification of impacted devices.

Impact

The impact of exploiting these vulnerabilities will vary widely, depending on the implementation options used while developing embedded systems that use NicheStack or NicheLite. As these vulnerabilities involve processing of network packets, attackers can generally abuse these errors via remote network access. In summary, a remote, unauthenticated attacker may be able to use specially-crafted network packets to cause a denial of service, disclose information, or in some cases be able to execute arbitrary code on the target device.

Solution

Apply updates

The most reliable way to address these vulnerabilities is to update to the latest stable version of NicheStack software mentioned in HCC Embedded mentioned in their Security Advisories. If you are unsure or have discovered NicheStack using open-source tools provided by Forescout, reach out to HCC Embedded via their PSIRT security team or to your upstream vendor in your supply chain to obtain the software fixes. HCC has also provided a register to be notified web page for sustaining this outreach for their long-standing customers.

Block anomalous IP traffic

CERT/CC recognizes that many implementations of NicheStack involve longer lifecycles for patching. In the meantime, if feasible, organizations can consider isolating impacted devices and blocking network attacks using network inspection, as detailed below, when network isolation is not feasible. It is recommended that security features available to you in devices such as router, firewalls for blocking anomalous network packets are enabled and properly configured. Below is a list of possible mitigations that address some specific network attacks that attempt to exploit these vulnerabilities.

• Provide DNS recursion services to the embedded devices using recursive DNS servers that are securely configured, and well-maintained with patches and updates.
• Provide HTTP access to embedded devices that are in an isolated network via securely configured HTTP reverse proxy or using HTTP deep packet inspection firewalls.
• Filter ICMP and TFTP access to embedded devices from the wider Internet and use stateful inspection of these protocols when accessible to wider Internet to avoid abuse.
• Enforce TCP stateful inspection for embedded device and reject malformed TCP packets using router, firewall features as available to the operational environment.

When blocking or isolating is not an option, perform passive inspection using IDS that can alert on anomalous attempts to exploit these vulnerabilities. See also our recommendations and IDS rules that were made available for Treck TCP/IP stack related vulnerabilities VU#257161 for examples.

Acknowledgements

Thanks to Amine Amri, Stanislav Dashevskyi, and Daniel dos Santos from Forescout, and Asaf Karas and Shachar Menashe from JFrog who reported these vulnerabilities and supported coordinated disclosure. HCC Embedded, the primary OEM vendor, also supported our efforts to coordinate and develop security fixes to address these issues.

This document was written by Vijay Sarvepalli.