Security experts from Tripwire, Imperva and ESET, discuss the severity of the issue.
Tim Erlin, Director of Security and Product Management at Tripwire:
“There’s an interesting cycle going on with OpenSSL vulnerabilities after Heartbleed. OpenSSL pre-announces a high severity vulnerability, which causes the information security community to start making noise about the ‘next Heartbleed.’ When the vulnerability is actually published, it always seems so much less severe because of all that pre-announcement hype.
However, this latest vulnerability is severe because it allows for an attack on the chain of trust, i.e. validation, of certificates used in the OpenSSL encryption process. That’s pretty fundamental to the service provided by OpenSSL, but it’s only ‘shocking’ or newsworthy if it were a surprise and we could speculate on how it’s been exploited in the past. It’s also worth noting that this affects only newer versions of OpenSSL, whereas Heartbleed was very widespread. It could never have been the next Heartbleed because it was pre-announced.
As a community, we’re experiencing one of the downsides of a low/medium/high ranking system for vulnerabilities, which is what the OpenSSL Security Policy uses. These broad categories don’t allow for some fairly important differentiation between vulnerabilities that are all considered ‘high.’ OpenSSL could use a more effective set of rankings, or even the Common Vulnerability Scoring System (CVSS), as a means to provide greater distinction. That would help organizations prepare more effectively.”
Craig Young, Security Researcher at Tripwire:
“This type of vulnerability poses a large risk for connections secured by OpenSSL as it potentially allows an attacker to forge “trusted” certificates opening the door for man in the middle attacks. Fortunately consumers generally don’t need to worry about this as most web browsers do not use OpenSSL and so are unaffected.
My concern would be more for system update processes to be subverted allowing attacker controlled code to be sent to a victim manipulating the update communication. Many embedded Unix/Linux derived systems may also be impacted. IoT devices for example might be targeted for data access or MiTM attacks against update servers.”
David Harley, Senior Research Fellow at IT Security Firm ESET:
“It’s significant in that it addresses a bug which could have been exploited to bypass checks on untrusted certificates, though I’m not aware of any instance where it was actually exploited. It’s worth remembering, perhaps, that it’s not unknown for a TLS certificate to be made available for a site that isn’t what it appears to be. I’m thinking of the recent case where a researcher registered a site with a name that resembled a legitimate bank’s domain name and had no problem buying a certificate for it. It’s important to remember that even when traffic is correctly encrypted it doesn’t mean that the traffic is legitimate.”
Itsik Mantin, Director of Security Research at Imperva:
What’s the vulnerability?
“The SSL trust ecosystem relies heavily on a “chain of trust”. When A trusts B and B trusts C then A trusts C.
This trust system allows web entities to communicate securely with each other, even before their first meeting, e.g., when a browser enters www.facebook.com for the first time.
Certificate Authorities (CA) play a significant role in this ecosystem, having the right to grant www.facebook.com with a proof that it is indeed www.facebook.com.
This tremendous power of Certificate Authorities is controlled with strict compliance and robustness rules a CA candidate need to comply with through a thorough certification process.
The new vulnerability gives web clients and servers the power to play the CA role under certain circumstances.
Thus every person with SSL identity, e.g., the owner of www.malware.com, can give anyone including itself, a proof that it iswww.facebook.com.
This invalid proof will be accepted by web clients and servers that use OpenSSL.
Who’s Affected?
Web clients and servers using OpenSSL library for SSL communication, when the OpenSSL is in one of the affected versions.
Is the common user vulnerable?
The OpenSSL library is very popular among web servers, but is rarely used in web clients.
In particular, all popular browsers, including Chrome, Firefox, Internet Explorer and Safari do not use OpenSSL for their SSL communication.
Thus the common user is not affected by the new vulnerability.
Which Web Servers are Vulnerable?
The most common usage of SSL is the server authentication scenario, where the client authenticates the server.
In this case the new vulnerability have no impact on the web server.
A less common usage of SSL, is where both the server and the client authenticate each other.
In this case a web server that uses OpenSSL can be potentially misled by a malicious client, impersonating as another.
Web servers that use client authentication with OpenSSL of one of the affected versions (1.0.1, 1.0.2), should upgrade to the patched versions (1.0.1p, 1.0.2d).”
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.