It is the responsibility of operating system vendors to ensure the integrity and security of the operating systems they provide to their customers (manufacturers of embedded system-based products) —and equally important — to inform their customers when vulnerabilities are identified. Unfortunately, in the case of VxWorks’ password hashing implementation, it appears that this responsibility has not been fulfilled.
This blog post covers a recently identified security vulnerability in the Wind River VxWorks operating system, the vendor's response, and our perspective on how this situation should have been handled.
Vulnerability Overview
We stumbled on the password hashing issues while performing a penetration test of a VxWorks-based OT device. Further information and proof of concept code can be found in our technical security advisory. Here is a summary about the different password hashing algorithms used in VxWorks 6.9 vs. 7 and how the vendor handled our coordinated vulnerability disclosure (CVD).
VxWorks 6.9: Weak Password Hashing Algorithm
The password hashing algorithm introduced in VxWorks 6.9 employs a single iteration of SHA-256 combined with a salt. While this approach replaced a proprietary and collision-prone hashing algorithm (CVE-2010-2965 by HD Moore), it is still woefully inadequate by modern standards.
Even in 2011, the year when the first version of VxWorks 6.9 was released, the use of a single iteration for password hashing was widely considered insufficient. For comparison:
- md5crypt (1994): 1,000 iterations.
- sha256crypt (2008): 5,000 iterations.
- VxWorks 6.9 (2011): one iteration
This makes the VxWorks 6.9 algorithm approximately 600,000 times weaker than today’s minimum recommendations for password storage, as outlined in the OWASP Password Storage Cheat Sheet for SHA-256.
Attackers can easily crack such passwords using GPU-based setups. Potential attack vectors for obtaining password hashes include:
- Physical access to device memory (e.g., through UART, JTAG, or dumping memory chips).
- Remote access to debugging interfaces.
- Extraction of firmware update files containing hard-coded accounts (e.g. vendor backdoors added via the loginUserAdd() function)
VxWorks 7: Incremental Improvements, But Still Behind
VxWorks 7, which is still the latest major version as of today, introduced a new proprietary hashing algorithm with 5,000 iterations of SHA-256. While this is an improvement over version 6.9, it still lags behind modern standards.
Embedded systems today have sufficient computational power to handle robust password hashing. Modern implementations, such as sha512crypt or PBKDF2 work in resource-constrained environments and come with a tune-able cost factor.
Vendor and our Response
The Wind River PSIRT received our security advisory in July 2024 but failed to take meaningful action or provide transparent disclosure. For VxWorks 6.9, they incorrectly claimed the system uses 5,000 iterations of SHA-256 for password hashing, despite our proof of concept demonstrating that it uses only a single iteration. They downplayed the severity of this issue, citing the product's End of Life (EOL) in three months as justification for inaction. For VxWorks 7, the vendor dismissed the need for further improvements, stating it was "appropriate for an embedded system". The vendor told us they are treating the issue as a "feature request" but were unable to provide a timeline for the implementation.
Later, we scheduled a meeting with the vendor and tried to convince them (rather diplomatically) to at least publish something on the issue - maybe a security advisory, technical documentation or a guidance for developers. But, they ultimately decided not to assign a CVE or release any material.
Conclusion
The single iteration hashing algorithm of VxWorks 6.9 is not just weak—it's practically an invitation for attackers to crack it. While VxWorks 7 improves things slightly, it’s still far behind modern standards and lacks flexibility. What's worse is the vendor's refusal to publish any further information or assign a CVE, leaving customers in the dark about this security issue. It's a failure in transparency and accountability that leaves everyone a little more vulnerable than they should be.
Fortunately, most vendors we engage within the SEC Consult Vulnerability Lab are far more responsible when it comes to product security. The advent of regulations like the EU Cyber Resilience Act (CRA) is also encouraging, as it aims to enforce stricter security requirements and transparency in software products, holding vendors accountable for their responsibilities. Under the EU Cyber Resilience Act, operating systems are classified as "important products with digital elements", a special category that places heightened obligations on vendors.
As embedded systems security researchers, we remain committed to pushing for better security practices, even if some vendors would rather bury their heads in the sand.
SEC Consult supports with professional penetration testing of IoT devices as well as embedded system pentesting including a specialized hardware lab in Vienna, comprehensive support for the OT environment and is an expert for professional penetration testing for IT infrastructures and software products.
