“Hello, I’m a VxWorks device. Would you like to own me?”
A recent report describes a critical and widespread vulnerability in electronics running VxWorks, an embedded real-time operating system (RTOS). Examples of affected devices include DSL concentrators, SCADA industrial automation systems, D-Link video conferencing systems, fibre channel switches, and Apple Airport Extreme wifi routers. The problem: a back-door diagnostic communications port provided by VxWorks. This debug connection was exploited by researcher H.D. Moore to commandeer the system. Any memory could be read or written: admin passwords extracted, supervisor mode malware trivially installed, etc. Moore revealed during his Thursday B-Sides security conference talk that a quarter million devices accessible directly from the Internet were found to be vulnerable.
This may sound eerily similar to my car hacking blog which discusses how 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 an RTOS: 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, and other management functionality.
The real message here is that there is a plethora of ways for embedded developers to innocently misuse systems software, exposing devices and placing their resources, missions, and attached networks at risk. Embedded security is not just about picking the right hardware and software technology. Equally important are security design and architecture, including configuration, isolation of security functions, platform vulnerability assessment, establishment of a secure initial state, fail-security, etc. While the answer to this VxWorks hack may seem as simple as disabling the diagnostics connection or adding authentication capability to it, a more systemic approach is often needed. What other open ports, buffer overflow flaws, unprotected data or other weaknesses may be present in a legacy software environment about which the developers may understand precious little?
And of course, disabling the diagnostics port removes what may be critical functionality for the end customer. Consider the following alternative approach. What if we could take the legacy environment - the RTOS and all of its applications - and encapsulate it (e.g. via virtualization or other some form of robust partitioning) within a bullet-proof cocoon that retains all the old functionality while adding a high assurance gateway for secure remote management? Here’s the picture:
If the security kernel is devoid of vulnerabilities and the network security / authentication apps were similarly developed to a high level of assurance, then hackers are thwarted while legitimate administrators can perform remote management. In fact, the trustworthy management application, because it is not running within VxWorks, can patch the entire VxWorks kernel itself. Embedded designers must work with security 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 embedded systems for more than 20 years and is one of the original developers of the INTEGRITY operating system, the first software technology certified to EAL 6+ High Robustness , the highest Common Criteria security level ever achieved for software. He managed INTEGRITYʼs development for a decade and now serves as the chief technology officer at Green Hills Software This is his personal blog; opinions expressed are not necessarily those of GHS.