Vulnerabilities

OpenSSL Patches Serious Certificate Forgery Vulnerability

The developers of OpenSSL have released versions 1.0.2d and 1.0.1p to address a high severity vulnerability that can be exploited by an attacker to bypass certain untrusted certificate checks and issue invalid certificates.

<p><strong><span><span>The developers of OpenSSL have released versions 1.0.2d and 1.0.1p to address a high severity vulnerability that can be exploited by an attacker to bypass certain untrusted certificate checks and issue invalid certificates.</span></span></strong></p>

The developers of OpenSSL have released versions 1.0.2d and 1.0.1p to address a high severity vulnerability that can be exploited by an attacker to bypass certain untrusted certificate checks and issue invalid certificates.

The issue, described by OpenSSL as an alternative chain certificate forgery flaw (CVE-2015-1793), was introduced with OpenSSL versions 1.0.1n and 1.0.2b released last month.

According to an advisory published on Thursday morning, the vulnerability is related to the certificate verification process. If the first attempt to build a certificate chain fails, OpenSSL will try to identify an alternative chain.

“An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and ‘issue’ an invalid certificate,” the OpenSSL Project team explained. “This issue will impact any application that verifies certificates including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication.”

The vulnerability was reported to the developers of the SSL/TLS toolkit on June 24 by Google’s Adam Langley and David Benjamin, who both work on BoringSSL, the search giant’s own version of OpenSSL. OpenSSL developers noted that the fix for CVE-2015-1793 was developed by members of the BoringSSL project.

This bug affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o. It does not impact the 1.0.0 or 0.9.8 releases, OpenSSL said. Users of OpenSSL 1.0.2b and 1.0.2c are advised to upgrade their installations to version 1.0.2d, while OpenSSL 1.0.1n and 1.0.1o users should upgrade to version 1.0.1p.

“Exploiting the OpenSSL vulnerability (CVE-2015-1793) is not quick or easy, making it nowhere near as serious as Heartbleed. For starters, an attacker can’t simply directly attack a vulnerable server due to the nature of the vulnerability,” Veracode’s VP of Research, Chris Eng, told SecurityWeek“Going after an individual is also challenging since the major browsers – Chrome, Firefox, IE – don’t use OpenSSL. Even if a user with a vulnerable niche browser were to be targeted, the culprit would have to first deploy a man-in-the-middle (MitM) attack to get access to the browser itself. From there, they would need to serve a forged certificate to the browser directly.”

“Since the bug only affects a few OpenSSL versions that were released in June 2015, major operating systems like RHEL, Ubuntu and CentOS are not vulnerable since they hadn’t yet incorporated the problematic updates at time of release. To be clear, this is a bad vulnerability and a nice find by the BoringSSL team; however, the overall impact is expected to be minimal,” Eng added.

Advertisement. Scroll to continue reading.

OpenSSL developers also took this opportunity to remind users that versions 1.0.0 and 0.9.8 will no longer be supported starting with December 31, 2015. After this date, security updates will not be provided for these versions.

The fact that it consists of more than 500,000 lines of code makes OpenSSL difficult to maintain and researchers constantly uncover security flaws.

None of the recently patched bugs are as serious as Heartbleed, the OpenSSL weakness that exposed millions of websites last year. However, since another Heartbleed could be discovered at any moment, experts are advising users to consider alternatives.

One alternative would be Amazon’s s2n, a new open source implementation of TLS designed to be simple, small, fast, and secure. s2n consists of only 6,000 lines of code and it has already undergone three external security evaluations and penetration tests. Amazon plans on integrating s2n into several AWS services in the upcoming period.

*Updated with information from Chris Eng.

Related Content

Copyright © 2024 SecurityWeek ®, a Wired Business Media Publication. All Rights Reserved.

Exit mobile version