OpenSSL 1.1.1 Sunset Risks Another Heartbleed in Embedded Apps

September 22, 2023

Blog

OpenSSL, a fundamental open-source cryptographic library, ensures secure communications across TCP/IP networks. It is widely used for SSL or TLS encryption by applications, systems, and devices worldwide.

However, as OpenSSL version 1.1.1 is reaching its end-of-life (EOL) in September 2023, there's growing urgency to migrate to newer versions to avoid another  Heartbleed incident, which exposed two-thirds of the world’s web servers to attack.

Understanding the Risks

The end of updates and security fixes for OpenSSL 1.1.1 makes systems that still use this version susceptible to new security threats. As hackers identify and exploit these loopholes, organizations using the outdated version risk unauthorized access, data breaches, and other security incidents.

These risks aren't merely technical. Organizations also face:

• Non-Compliance: Regulatory frameworks mandate the use of secure software versions. Insecure OpenSSL versions can lead to non-compliance, incurring penalties.
• Data Exposure: OpenSSL’s role in encryption means its vulnerabilities can jeopardize data integrity and confidentiality.
• System Instability: Beyond security, outdated OpenSSL might also affect software application stability and performance.
• Reputation Damage: A breach resulting from OpenSSL vulnerabilities can erode customer trust and tarnish a brand's image.

Detection Challenges

OpenSSL 1.1.1 is often embedded in third party components used to build software and hardware products. These "baked in" versions are therefore difficult to detect. For example, many embedded devices, such as IoT edge devices or home medical products, use third-party operating systems and network stacks. The versions of these products are seldom updated once a product is released, and vulnerabilities increase as products age.

It’s also difficult to update many of the applications and devices that use OpenSSL since their software or firmware was never designed to be updated. As a result, out of date and insecure versions of OpenSSL are still common in IoT devices. This is likely to continue with version 1.1.1 since no security updates will be forthcoming.

Software Bill of Materials

One effective way to identify the presence of vulnerable software libraries is Binary Software Composition Analysis (BSCA). By analyzing binaries, BSCA maps components like OpenSSL against known vulnerabilities in software versions using vulnerability databases and advisories, and allows for efficient detection.

For deployed products, BSCA can create a Software Bill of Materials (SBOMs) with a comprehensive vulnerability report to accurately identify the presence of OpenSSL including versions numbers. In addition, BSCA provides the following benefits:

Comprehensive Coverage: BSCA inspects the entire software stack, including all the dependencies and libraries linked during the compilation process. This holistic approach ensures that insecure versions of OpenSSL, whether directly or indirectly used by the application, are identified.

Detection of Transitive Dependencies: Open-source software often relies on other open-source components, creating complex dependency chains. BSCA can identify the indirect or transitive dependencies of OpenSSL within the software stack which is critical since outdated or insecure versions of OpenSSL are often buried.

Speed and Efficiency: Because BSCA analyzes compiled binaries, it does not require access to source code or recompilation. This results in faster scanning and enables organizations to quickly assess whether their applications are vulnerable to insecure OpenSSL versions without the need for extensive manual code reviews or reverse engineering.

Application-Agnostic: BSCA can be applied to software written in various languages, making it suitable for diverse environments and technologies that use OpenSSL.

Continuous Monitoring: BSCA can be integrated into the software development lifecycle as part of a continuous integration/continuous deployment (CI/CD) pipeline. This enables ongoing monitoring, ensuring that any new vulnerabilities or insecure versions of OpenSSL introduced through updates or new dependencies are promptly detected.

Risk Remediation Best Practices

Addressing the risk associated with end-of-life open-source libraries like OpenSSL involves careful planning and implementation. Here are some options to consider:

 Vendor support: If OpenSSL exposure is associated with third-party software that uses the library, contact the vendor. They should offer extended support and maintenance services for end-of-life software, including open-source libraries. 

Upgrade or replace: If possible, upgrade to a supported version of OpenSSL that is actively maintained and receives security updates. The new long-term support (LTS) version of OpenSSL is version 3.0.

Workaround, isolate, and restrict: Isolate the use of the outdated library within the application, network, or system, limiting its exposure to potential attackers. Restrict access to the library and closely monitor its use for signs of compromise. If this isn’t possible, consider the network isolation of affected devices behind a firewall. This is a last resort, but it may be necessary for legacy devices with no support.

Given the damage from Heartbleed in 2014 and the fact that many devices are still exposed to the vulnerability, the security risks associated with using an EOL version of OpenSSL can’t be underestimated. Organizations should immediately start evaluating whether they are exposed to OpenSSL 1.1.1 and take remediation steps before its end of life to avoid the next Heartbleed.

About the author: Mark Hermeling, senior director of product marketing for CodeSecure, formerly the product division of GrammaTech, has more than 20 years of experience in software development tooling, operating systems, virtualization and networking technology in safe and secure, embedded and real-time systems. He has worked on projects building automotive, networking, aerospace and defense and industrial devices in North America, Europe and Asia. Mark also worked for Wind River Systems (an Intel Corporation subsidiary), Zeligsoft and IBM Rational.