“Hello, I’m a VxWorks device. Would you like to own me?” - Embedded.com

“Hello, I’m a VxWorks device. Would you like to own me?”

A recent report describes a critical and widespread vulnerability inelectronics running VxWorks, an embedded real-time operating system(RTOS). Examples of affected devices include DSL concentrators, SCADAindustrial automation systems, D-Link video conferencing systems, fibrechannel switches, and Apple Airport Extreme wifi routers. The problem:a back-door diagnostic communications port provided by VxWorks. Thisdebug connection was exploited by researcher H.D. Moore to commandeerthe system. Any memory could be read or written: admin passwordsextracted, supervisor mode malware trivially installed, etc. Moorerevealed during his Thursday B-Sides security conference talk that aquarter million devices accessible directly from the Internet werefound to be vulnerable.

This may sound eerily similar to my car hacking blog which discusseshow a diagnostics port was used to subvert a car’s brakes and engine.What I didn’t mention then is that this hacked system also runs anRTOS: QNX. Embedded devices, historically thought of as autonomous,closed systems, are increasingly constituents of the Internet of Things, with requirements for in-field upgrade, debug/diagnostics, andother management functionality.

The real message here is that there is a plethora of ways for embeddeddevelopers to innocently misuse systems software, exposing devices andplacing their resources, missions, and attached networks at risk.Embedded security is not just about picking the right hardware andsoftware technology. Equally important are security design andarchitecture, including configuration, isolation of security functions,platform vulnerability assessment, establishment of a secure initialstate, fail-security, etc. While the answer to this VxWorks hack mayseem as simple as disabling the diagnostics connection or addingauthentication capability to it, a more systemic approach is oftenneeded. What other open ports, buffer overflow flaws, unprotected dataor other weaknesses may be present in a legacy software environmentabout which the developers may understand precious little?

And of course, disabling the diagnostics port removes what may becritical functionality for the end customer. Consider the followingalternative approach. What if we could take the legacy environment -the RTOS and all of its applications – and encapsulate it (e.g. viavirtualization or other some form of robust partitioning) within abullet-proof cocoon that retains all the old functionality while addinga high assurance gateway for secure remote management? Here’s thepicture:

If the security kernel is devoid of vulnerabilities and the networksecurity / authentication apps were similarly developed to a high levelof assurance, then hackers are thwarted while legitimate administratorscan perform remote management. In fact, the trustworthy managementapplication, because it is not running within VxWorks, can patch theentire VxWorks kernel itself. Embedded designers must work withsecurity experts to determine the best approach, given resource,legacy, and other constraints, for deploying remote management -safely.


Dave Kleidermacher has been developing systems software for high criticality embeddedsystems for more than 20 years and is one of the original developers ofthe INTEGRITY operating system, the first software technology certifiedto EAL 6+ High Robustness , the highest Common Criteria security levelever achieved for software. He managed INTEGRITYʼs development for adecade and now serves as the chief technology officer at Green HillsSoftware This is his personal blog; opinions expressed are notnecessarily those of GHS.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.