Oh sh*t's, 11: VxWorks stars in today's security thriller – hijack bugs discovered in countless gadgets' network code Wind River has patched 11 security vulnerabilities in VxWorks that can be potentially exploited over networks or the internet to commandeer all sorts of equipment dotted around the planet. This real-time operating system powers car electronics, factory robots and controllers, aircraft and spacecraft, wireless routers, medical …
When it comes to having a NIC plugging into a hostile network, VxWorks is not the OS that springs to mind as being one designed and intended to survive the experience unharmed. It's a great hard real-time OS, but it's not one that I'd automatically rely on for security applications. Still, good to see they're fixing flaws which will always improve things.
Well they do test it. The Windriver stack is subject to both Achilles test (DoS and stack fuzzing) and Nessus tests, as well as Coverity static analysis tests. What happened is that they went to another outfit to further test the stack and this outfit came up with the 11 vulnerabilities several months ago that have just been publically disclosed.
So here's how it worked:
Our industrial controller uses vxWorks and we were notified of the vulnerabilities under NDA on 26th June. Along with the notification Windriver supplied us with the patches to the OS to fix the vulnerabilities, and provided a test harness to confirm that the patches were correctly implemented on our product. This gave us over a month to pull the patches in, rebuild the versions of our product that were affected and retest the network part of the stack. It was tight but we managed it. It should also be noted that Windriver provides its OS in source code form (who doesn't?) so we could inspect the patches and make our own conclusions and tests.
And yes, vxWorks has built in security features .. although I suspect that many product builders wouldn't include the firewall component that Windriver supply as a component of the OS. 4 of the vulnerabilities can be mitigated by applying firewall rules.
Most RTOS-based machines are stuffed to the gunnels with code already, there usually isn't space for any other code to be downloaded, apart from trivially small stuff.
Also you'll need to write it in native machine code for that CPU and device map.
Cripes - it's hard enough linking new code in with the official build system so it doesn't crash, let alone loading an iffy binary patch.
Though if crashing is the attack?
Taking a factory plant down for 30sec is often more than enough to ruin an entire batch, and (given that it's supposed to be a safety-critical OS) may also be enough to cause physical destruction.
Or even kaboom, though one hopes the passive safety devices will prevent that.
So lots of warnings about all the critical devices that might be affected, but the actual VxWorks versions intended for those things aren't affected?
So are all the dire warnings true or not? They seem to talk worst case a lot (scope of effect on important kit and difficulty of fixing certified kit) while also letting slip that this sort of thing should never have been impacted anyway.
A certified RTOS is a special beast for all sorts of reasons so I'd really hope no one used a normal version in anything that mattered.
I wouldn't worry about aircraft and spacecraft. Here's how Wind River characterized it:
"Connected devices leveraging standard VxWorks releases that include the IPnet stack are impacted by the discovered vulnerabilities. They primarily include enterprise devices located at the perimeter of organizational networks that are internet-facing such as modems, routers, firewalls, and printers, as well as some industrial and medical devices."
It's not great, it's not terrible. Not as terrible as some other publications have wailed.
C.
The Register - Independent news and views for the tech community. Part of Situation Publishing
Biting the hand that feeds IT © 1998–2021
