Vulnerability

Interpeak IPnet TCP/IP stack flaws reach VxWorks and other RTOS builds in medical devices

MedDevice Cyber Staff · Oct 1 · 4 min read · Via CISA ICSMA-19-274-01

CISA published medical advisory ICSMA-19-274-01 on October 1, 2019, for 11 vulnerabilities in the Interpeak IPnet TCP/IP stack. Gregory Vishnepolsky, Dor Zusman and Ben Seri of Armis reported them. IPnet was licensed into several real-time operating systems, so the advisory names Wind River VxWorks (6.5 and earlier, versions under current support including 6.9.4.11, Vx7 SR540 and Vx7 SR610, VxWorks 653 MCE 3.x and the bootrom network stack), ENEA OSE 4 and 5, Green Hills INTEGRITY RTOS 2003 to 2006, and ITRON implementations.

Three bugs score CVSS v3 9.8 with no privileges or interaction needed. CVE-2019-12256 is a stack overflow in IPv4 option parsing, triggered by packets with invalid options. CVE-2019-12255 (integer underflow) and CVE-2019-12260 (memory bounds) can overflow an application buffer by up to a full TCP receive window, 10k to 64k by default depending on version, in the task calling recv().

CVE-2019-12255 lets an attacker hijack an existing TCP session or open a new one on any listening port to deliver the bad segments. Applications that pass a stack-allocated buffer are the easiest to exploit. CVE-2019-12257 (CVSS 8.8) is a heap overflow in the DHCP client, which also runs in the bootrom during boot.

The rest are LAN-adjacent or availability bugs. CVE-2019-12263 (CVSS 8.1) is a race condition between the network task and the receiving application. CVE-2019-12258 (CVSS 7.5) lets an attacker who knows a session's ports and addresses reset it. CVE-2019-12262, CVE-2019-12264, CVE-2019-12259 and CVE-2019-12265 cover reverse-ARP and DHCP address abuse, a NULL pointer dereference and IGMPv3 fragment handling.

The fix path runs through each RTOS vendor and then each device maker. Wind River produced patches, available from its PSIRT by VxWorks major version. Green Hills informed affected users and offered consulting. Enea said it had no IPnet customers on support in the United States, and the TRON Forum said each ITRON user must check whether an Interpeak stack is inside its product.

For a hospital, the question is which bedside and lab devices carry an affected RTOS, and the answer sits with each manufacturer. CISA's advice is the standard set: minimize network exposure, keep devices behind firewalls and off business networks, and use a VPN for remote access.

A network stack is a third-party component like any library, and it belongs in the SBOM with its version. Manufacturers that cannot answer whether IPnet is inside their firmware within a day have a component inventory problem.

Are you a representative of Interpeak or Wind River or ENEA or Green Hills Software? Submit an official response →

Remediation Desk

For ProvidersOperators, hospitals, and clinical engineering

Device makers should confirm whether their firmware includes an Interpeak IPnet stack, obtain the Wind River patches or their RTOS vendor's fix, and ship updated firmware. Hospitals should ask each manufacturer for a product-by-product statement and, until updates arrive, keep affected devices behind firewalls, off business networks and unreachable from the internet.

Check the SBOM for IPnet. Identify every product whose RTOS (VxWorks, OSE, INTEGRITY or an ITRON implementation) includes the Interpeak IPnet stack.
Obtain RTOS patches. Request source patches from Wind River PSIRT for the relevant VxWorks major version, or the equivalent from other RTOS vendors.
Isolate affected devices. Keep in-scope devices behind firewalls, separate from business networks, until firmware is updated.
Track network stacks as components. List the TCP/IP stack and its version in every product SBOM so the next stack advisory is answered in hours.

For Device ManufacturersAm I affected, and how to fix the class

Am I affected?

This class applies to devices with the signals and properties below. Check them against your product to gauge exposure. The named product rows list what the sources state about the affected product.

Contributing

Wired network Off-the-shelf software Hospital network

IPnet TCP/IP Stack

PID-41 Off-the-shelf software

VxWorks

PID-21

Fix the class in your product

The advisory is not for a bug you wrote; it is in a component you embed. As the maker, pin dependencies to fixed versions, generate an SBOM on every build including transitive components, and gate the pipeline on known-vulnerable components so an advisory maps to your products automatically.

Pin and inventory. Exact versions, and a CycloneDX or SPDX SBOM as a build artifact including transitive deps.
Gate on advisories. A CI scan fails a release carrying a component with a known advisory.
Own the field patch path. Know how you deliver a dependency or platform patch to fielded devices before you need it.

Mapped EMB3D mitigations

Questions & Answers

What medical devices are affected by the Interpeak IPnet vulnerabilities in ICSMA-19-274-01?

CISA advisory ICSMA-19-274-01, published October 1, 2019, covers 11 IPnet TCP/IP stack vulnerabilities in RTOS builds including Wind River VxWorks, ENEA OSE 4 and 5, and Green Hills INTEGRITY 2003 to 2006. Any medical device built on an affected RTOS with IPnet is in scope, and each manufacturer has to confirm its own products.

What is CVE-2019-12256 in the IPnet TCP/IP stack?

CVE-2019-12256 is a stack-based buffer overflow (CWE-121, CVSS v3 9.8) in IPnet's IPv4 option parsing, triggered by IPv4 packets with invalid options. Per CISA advisory ICSMA-19-274-01 it most likely crashes the tNet0 task and can result in remote code execution.

How do I get patches for the VxWorks IPnet vulnerabilities?

Per CISA advisory ICSMA-19-274-01, Wind River has produced patches and controls for the IPnet vulnerabilities, including CVE-2019-12256 and CVE-2019-12255; device makers request source patches from Wind River PSIRT by VxWorks major version.

← Back to Vulnerabilities