VxWorks Vulnerabilities Impact Numerous Vendors

Two critical security bugs have been uncovered in the VxWorks operating system powering products from Apple, Nokia and numerous other vendors.

VxWorks is developed by Wind River Systems, now owned by Intel. Designed for use in embedded systems, VxWorks is a real-time operating system used to power a wide range of devices, including printers, fibre-channel switches and other products. A list of affected vendors that have issued updates can be found in CERT advisories here and here.

According to HD Moore, chief security officer at Rapid7, the vulnerabilities rest in the VxWorks debug service and the hashing algorithm used in the standard authentication API for VxWorks. If exploited, the flaw in the VxWorks debug service (WDB Agent) could permit an attacker to potentially hijack the entire operating system. The service, he explained, was inadvertently left open to attack by more than 100 different vendors.

“Since VxWorks provides the operating system, but the manufacturers are responsible for building the final firmware image for their products, whether a particular product is still vulnerable depends on how that specific manufacturer responded,” Moore told eWEEK. “In the case of the exposed debug service, Wind River Systems sent an advisory to their customer base that basically said ‘don't do that’. CERT reached out to as many of the identified manufacturers as possible and relayed my findings. Only a handful of the manufacturers with affected devices actually replied to CERT with an update.”

The story is similar for the hashing vulnerability, he said. An attacker with a known username and access to a service such as telnet or FTP that uses the standard authentication API can brute force the password in a relatively short period of time. Like the Debug Service flaw the core problem exists in the VxWorks' software. However, hundreds of downstream vendors are likely to be affected, Moore said.

“All CERT was able to do was call down the list of VxWorks customers and ask them to verify their products,” he said. “Again, only a handful of vendors replied indicating yes/no to this issue. In this instance, Wind River Systems provided sample code to their customers for how to work around this issue. For the bug to be actually fixed for a specific device, the manufacturer would need to take this code from Wind River Systems, build a new firmware update, then distribute this update to their own customers.”

According to Moore's findings, the flaw occurs because there are only 210,000 possible hash outputs for all possible passwords. An attacker can cycle through the most common ranges of hash outputs of about 8,000 work-alike passwords to gain access to a VxWorks device. Using the FTP protocol, this attack would only take about 30 minutes to try all common password permutations.

Among the advice from CERT is a recommendation that vendors using VxWorks in their products ditch the default hashing algorithm in the standard authentication API in favor of a trusted authentication API.

To address the Debug Service issue, vendors can remove the WDB target debug agent in their Vxworks-based products by removing the INCLUDE_WDB & INCLUDE_DEBUG components from their VxWorks Image. In addition, enterprises worried about the issue can adjust their firewall rules to restrict access to the debug service over UDP port 17185 to only trusted sources until affected vendors release a patch.

Moore gave presentations on the issues last week at the Security B-sides and DEFCON 18 conferences in Las Vegas.

A spokesperson for Wind River said the company respond and "distributed patches and remediation steps" in conjunction with the CERT announcement. 

"Once CERT notified Wind River, Wind River immediately assessed the alert and was restricted to release a synchronous public response," the spokesperson said in a statement. "Wind River’s VxWorks continues to be the most widely deployed real-time operating system in mission-critical embedded systems."