CVE-2020-35198: Wind River VxWorks Buffer Overflow Flaw

CVE-2020-35198 Overview

An integer overflow vulnerability exists in Wind River VxWorks 7's memory allocator. The vulnerability occurs in the calloc() function when calculating the size of a memory block to be allocated. When specific argument values are provided, the size calculation can overflow, resulting in the allocation of a memory buffer that is significantly smaller than expected. This leads to memory corruption when the application subsequently writes data beyond the actual allocated buffer boundary.

This vulnerability is particularly concerning in embedded systems and real-time operating system (RTOS) environments where VxWorks is commonly deployed, including industrial control systems, medical devices, aerospace systems, and telecommunications infrastructure.

Critical Impact

Remote attackers can exploit this integer overflow vulnerability to corrupt memory, potentially achieving arbitrary code execution or causing denial of service on affected VxWorks systems without requiring authentication or user interaction.

Affected Products

• Wind River VxWorks 7
• Wind River VxWorks 6.9.4.12 (including Rolling Cumulative Patch Layer 1 and 2)
• Oracle Communications Eagle (versions up to and including 46.7.0)

Discovery Timeline

• 2021-05-12 - CVE-2020-35198 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2020-35198

Vulnerability Analysis

The vulnerability resides in the memory allocator component of VxWorks, specifically within the calloc() function implementation. The calloc() function is designed to allocate memory for an array of elements, initializing all bytes to zero. It takes two parameters: the number of elements and the size of each element, then multiplies these values to determine the total memory required.

The integer overflow occurs during this multiplication operation. When the product of the number of elements and element size exceeds the maximum value representable by the integer data type used for the calculation, the result wraps around to a small value. This causes calloc() to allocate a memory buffer much smaller than the caller expects.

When the calling code then attempts to use this buffer as if it were the requested size, it writes beyond the bounds of the allocated memory. This out-of-bounds write corrupts adjacent memory regions, potentially overwriting critical data structures, function pointers, or return addresses.

Root Cause

The root cause is CWE-190: Integer Overflow or Wraparound. The VxWorks memory allocator fails to properly validate that the multiplication of the two calloc() arguments does not overflow before using the result to allocate memory. Safe implementations typically check whether the multiplication would overflow before performing it, or use compiler built-ins that detect overflow conditions.

Attack Vector

This vulnerability is exploitable over the network without requiring any privileges or user interaction. An attacker can trigger the vulnerable code path by sending specially crafted network packets or data that cause the target application to call calloc() with attacker-controlled size parameters. The network-based attack vector makes this vulnerability particularly dangerous for internet-facing VxWorks devices or those accessible on internal networks.

The exploitation flow involves:

1. Identifying an application or service on VxWorks that uses calloc() with externally-influenced parameters
2. Crafting input values that cause the size multiplication to overflow
3. Triggering memory corruption when the application writes to the undersized buffer
4. Leveraging the corruption to achieve code execution or system crash

Detection Methods for CVE-2020-35198

Indicators of Compromise

• Unexpected system crashes or reboots on VxWorks-based devices
• Memory corruption errors or segmentation faults in application logs
• Anomalous network traffic targeting VxWorks services with unusually large size parameters
• Evidence of heap corruption or inconsistent memory state in crash dumps

Detection Strategies

• Monitor for network traffic containing abnormally large numeric values in size-related protocol fields
• Implement memory protection mechanisms such as heap canaries or guard pages where supported
• Deploy network intrusion detection signatures targeting known VxWorks exploitation patterns
• Review application logs for memory allocation failures or corruption indicators

Monitoring Recommendations

• Establish baseline behavior monitoring for VxWorks device stability and restart frequency
• Configure alerting for unexpected device downtime or repeated crash-and-restart cycles
• Implement network segmentation and monitor traffic to/from VxWorks systems
• Deploy asset inventory to identify all VxWorks deployments including Oracle Communications Eagle systems

How to Mitigate CVE-2020-35198

Immediate Actions Required

• Identify all Wind River VxWorks deployments in your environment, including version 7 and 6.9.4.12 variants
• Inventory Oracle Communications Eagle deployments running versions up to 46.7.0
• Apply network segmentation to isolate affected devices from untrusted networks
• Implement strict firewall rules to limit network exposure of vulnerable systems

Patch Information

Wind River has released security patches addressing this vulnerability. Affected organizations should apply the latest updates from the Wind River Security Notices portal. For detailed CVE information, refer to the Wind River CVE-2020-35198 advisory.

Oracle has addressed this vulnerability in Oracle Communications Eagle as part of the April 2022 Critical Patch Update. Organizations using Oracle Communications Eagle should consult the Oracle Security Alert CPU April 2022 for upgrade guidance.

Workarounds

• Implement network access controls to restrict connections to affected devices from trusted sources only
• Deploy Web Application Firewalls (WAF) or network intrusion prevention systems configured to detect integer overflow exploitation attempts
• Disable or restrict unnecessary network services on VxWorks devices to reduce attack surface
• Where possible, implement input validation at the application layer to reject abnormally large size parameters before they reach the memory allocator