URGENT/11 and other recent vulnerabilities such as AMNESIA:33 related to embedded TCP/IP stacks indicate a deficiency in vetting and auditing software supply chains. The blame doesn’t rest solely on software vendors, but also points to the need for embedded device manufacturers to evaluate more than just their currently developed products.
Meanwhile, this issue is not limited to embedded software, or TCP/IP stacks specifically. Rather it exposes the security risk exposure created by the re-use of software components and the frequent discovery of new vulnerabilities associated with them.
Embedded TCP/IP Stacks: A Common Weakness?
Let’s take a closer look at the Urgent/11 and Amnesia:33 vulnerabilities. Both are in embedded TCP/IP stacks which is concerning since the network connection is the most likely attack vector for internet of things (IoT) devices commonly used in consumer, medical and industrial applications. Although the network stacks on affected devices is a common weakness, these vulnerabilities are most often related to outdated versions of the software. Vulnerabilities are concerning, but they can be fixed and patched.
What is more alarming is that known vulnerabilities are not being patched. As of December 2020, 97% of URGENT/11 vulnerable devices remained unpatched. This can be attributed in part to a lack of understanding by embedded systems vendors, end users, resellers and integrators of their exposure to these vulnerabilities.
URGENT/11 – Interpeak IPnet TCP/IP Stack
Probably the most well-known set of vulnerabilities is URGENT/11 which, originally affiliated with Wind River VxWorks, affects the Interpeak IPnet embedded TCP/IP stack used by many popular embedded real time operating systems (RTOS) and is commercial software. The vulnerabilities in URGENT/11 represent a who’s who of software weaknesses: buffer overflow, integer underflow, memory buffer out of bounds access, race conditions, argument injection, and null pointer dereference.
The products affected commonly use embedded operating systems (OSes) from ENEA, GreenHills Software, ITRON, IP Infusion ThreadX, and Wind River. In all cases these vendors have updated or replaced the affected IPnet TCP/IP stack in their products. However, older versions of these OSes are still running on millions of devices.
AMNESIA:33 – Multiple Embedded TCP/IP Stacks
Similar to URGENT/11, the AMNESIA:33 set of vulnerabilities relate to a group of embedded open-source TCP/IP stacks (uIP-Contiki, uIP, open-iscsi, picoTCP, FNET and Nut/Net.) Again, the underlying software weaknesses are also straight from the CWE Top 25; integer wraparound, out-of-bounds read and writes, integer overflow, improper input validation, and improper null termination.
A good example of this scenario is picoTCP, a very small footprint, open source, TCP/IP stack used in many IoT devices. The project seems to be at the end of life with little development in the last few years (looking at GitHub activity, latest commit as of writing this post was 15 months ago, most of the source hasn’t been touched in over four years.) Despite this fact, it is used in countless products that are now susceptible to compromise using the Amnesia:33 vulnerabilities.
TCP/IP stack vulnerabilities such as URGENT/11 and AMNESIA:33 are prevalent in both commercial and open source embedded components, and illustrate the importance of maintaining due diligence for all types of third party software that is going to be integrated into a device.
Software Bill of Materials (SBOM)
The most effective way to audit and manage vulnerabilities in embedded device software components is by maintaining a software bill of materials (SBOM). This approach not only accounts for custom-built software but also the RTOS, libraries (commercial and open source), board support packages, everything used in the product. A SBOM will also include components that make up commercial (e.g. RTOS and add-ons such as TCP/IP stacks) and open source products including an itemization of all versions and known vulnerabilities. The holistic nature of the SBOM is important since any product is only as secure as the most insecure component within it.
A SBOM is created using software composition analysis (SCA). However, SCA tools can’t rely on the availability of source code alone since many commercial products are only available as binary files. Instead, SCA tools that use binary analysis are required to detect and inspect binaries created during the release, integration and build stages of development.
SBOM for Closed Source and Commercial Products
For example, SCA tools that rely on source code cannot detect vulnerabilities in binary code which is the most likely way third party products are provided. RTOS and other embedded software is often prebuilt for specific target architectures and only board support packages are customized and compiled locally by customers.
Products in Development
A SBOM should be maintained at various stages of the product lifecycle, since vulnerabilities are constantly being found and a previously secure component can become insecure. It enables development teams to perform due diligence on third party products they are using. As long as a binary signature is available for a vulnerability, it is possible to detect at risk components. At this early stage, it is easy to patch, update or replace the product. It’s also important to update the SBOM as part of any existing process whether that’s a CI/CD pipeline or another process.
Products in Production and End of Life
Products that are shipping or end of life traditionally get less attention when it comes to security. The fact that URGENT/11 and AMNESIA:33 are related to outdated and end of life products, indicates that security is an entire lifecycle concern. The advantage of using binary analysis is that existing and legacy products can be analyzed to create SBOMs for entire product lines. This provides early warning of possible security exposures for both embedded device developers but also the vendors they rely on.
Summary
Using SCA to create SBOMs for product portfolios is an important step in cataloguing components and integrated third party software to be able to detect the presence of known vulnerabilities. This approach allows manufacturers to establish and maintain an organization-wide repository of both open source and internal/closed source libraries and executables, so they know what’s actually in the software they deliver.
