Of the 11 zero-day vulnerabilities found by Armis, six “are critical and enable Remote Code Execution (RCE).” In this post, we examine how this discovery indicates the importance of embedded security.
It’s one of the most important and widely-used OS in the world. Provided by Wind River Systems, VxWorks is used by more than 2 billion devices across industries as varied as aerospace and defense, robotics, automotive, and medical devices.
Late last month, researchers from Armis exposed 11 zero-day vulnerabilities in VxWorks, including six that “are critical and enable Remote Code Execution (RCE),” bringing this vastly deployed OS into the limelight for the wrong reasons.
The vulnerabilities that can lead to Remote Code execution are the most troubling, in that with RCE, an attacker can compromise the device and take control. Armis stated that the vulnerabilities mean attackers can take over devices with no need for user interaction and can bypass perimeter security like firewalls. This makes the vulnerabilities “wormable,” meaning they can propagate malware into other networks.
Wind River immediately issued a patch for VxWorks and any manufacturers using VxWorks are advised to check for the latest Wind River Security Alert updates and patch them immediately.
An IT Practice That Falls Short for Product Security
Since the vulnerabilities were discovered by Armis, the company has worked together with Wind River to notify customers and provide patches and other mitigation options, according to a statement from Wind River.
Wind River stated that only “a small subset of our customer base” uses versions of VxWorks that are affected by the vulnerabilities, and that they doubt the 200 million devices figure given by Armis is accurate. The company also recommends that customers take advantage of their long-term security services, security assessments, embedded security training, and customized solutions that can be crafted according to each customer’s specific needs.
Applying a patch after a vulnerability has been found is a stop gap solution that most IT organizations are accustomed to (maybe not Equifax…). For the patch to work, the IT security team has to be on top of things but their vigilance may not be enough if the patch is for the OS of a product, and the IT team must wait for it to be provided by the manufacturer.
Patching an embedded system is a difficult, expensive procedure, and it is not foolproof. The embedded product manufacturer must apply the patch and recompile the whole image as fast as possible, while also making time for the necessary and thorough testing required. Unlike software only solutions, embedded products require coordination with hardware platforms both in terms of the technical aspect and the supply chain. Timing of these processes is crucial. The overall process of software patching is disruptive and it can delay production line efficiencies and product delivery.
Exposure to Day-1 Attacks
When the patched image is finally ready it is provided as an update to the customers. But many of those IoT devices don’t have a regular/simple mechanism to update software. Devices that are not patched are exposed to Day-1 attacks, in particular from hackers who heard of the vulnerability and are working to take advantage of unpatched devices.
You see where this is going - a vulnerability is discovered in a device that has sold millions of copies to consumers. For them to remain safe, they must install the new update from the manufacturer, but is there any mechanism in place to make sure that customers using the former version also receive and install the patch? How complicated is the update? Does it require purchasing the latest version of the product?
Embedded Security Seals the Device Against Attacks
Urgent11 and the logistical difficulties of applying patches illustrate the need for built-in product security upfront. Today’s embedded systems contain a wide variety of in-house and 3rd-party code. The OS is just one aspect of a complex software image creation that needs to be ready for the full device manufacturing project. Optimizing hardware resource normal development is done in C/C++ and as such, memory corruptions like Buffer Overflow are a recurring nightmare.
Every application, library, or script of the image can have vulnerabilities. By installing built-in product cybersecurity, manufacturers can procure a higher level of safety and security than ever before.
Today’s standards are calling for software integrity - in boot and runtime – with the full realization that product security is different than the IT retroactive patching process. When the system is running, Control Flow Integrity (CFI) is one of the most effective, state-of-the-art forms of cybersecurity.
CFI prevents RCE by defining all valid destinations and stopping attempts to divert the program from its factory settings. With CFI built-in, malware is unable to divert the execution of a program.
With Karamba’s XGuard security suite protecting the full image in runtime, the discovery of the VxWorks critical vulnerabilities would have had a much higher bar to pass. The system would have auto-detected the exploit attempt as a deviation from the devices’ known-good state and would automatically block attempts to change the program flow.
By blocking the exploit attempts, XGuard eliminates the need for post attack attempt patch updates, thus helping maintain business continuity. After the exploit attempt is logged, the product manufacturer would have enough time to release a new, well-tested image with better security.
Karamba Security recently announced a partnership with Wind River and is happy to offer XGuard built-in protection to Wind customers. Customers that use new and older versions of VxWorks can now harden their systems against future exploits of other zero-day vulnerabilities that may exist in the OS, the application, or in 3rd-party code.
