Get ready to patch 'severe' bug in OpenSSL this Thursday

[Chiefcrowe]

http://www.theregister.co.uk/2015/0..._to_patch_severe_bug_in_openssl_this_thursday

 

[MustISO]

Looking forward to it. Unfortunately the vendors who use OpenSSL may be very slow to release patches for their software.

 

[Red Squirrel]

I'm starting to think it might be best to just disable SSL on my web server and block port 443... Makes you wonder how many exploits the NSA knows about that the public/coders do not.

 

[John Connor]

I'm so sick and tired of these OpenSSL vulnerabilities. Anything classified "Open" needs to be checked by an organization.

 

[Elixer]

I'm so sick and tired of these OpenSSL vulnerabilities. Anything classified "Open" needs to be checked by an organization.

They are now being checked...that is how they found this one.
Just goes to show you that people don't have security in mind back when all this code was made.

 

[seepy83]

Just goes to show you that people don't have security in mind back when all this code was made.

Not necessarily true. This most recent vulnerability that needs to be patched only affects some recent builds that were compiled after a code commit from 1/27/2015. I would go out on a limb and say that, at this point, most people who are contributing to projects like OpenSSL are very security-conscious. But people make mistakes, and writing bullet-proof code is very hard.

There aren't a lot of products or linux distros that are shipping with the vulnerable version of OpenSSL. Royce Williams has a pretty comprehensive list of apps, OSs, and builds that are affected on his site here http://www.techsolvency.com/story-so-far/cve-2015-1793_openssl-cert-forgery/

This bug is also unique, because the vulnerability is in Client-Based authentication. This isn't something that's used on your average https web server connection. Your typical https web server is just doing server-side authentication for TLS where the web server is presenting a certificate to the client and, as long as the client trusts that cert, the ongoing communication between the client and server are encrypted.

Certificate-based client authentication is more common internally in a Business/Enterprise/Gov't network. It's mutual authentication where both the client and server present a certificate for proof of who they are. With the bug, the certificate chain on the client side isn't validated by the server, so the client can use its own CA to issue a cert and the server will trust it. So, it's important for admins that are running vulnerable systems to get them patched, especially if they're doing client auth, but this vulnerability doesn't look like it will have as much impact that something like Heartbleed would have.

 

[matricks]

This bug is also unique, because the vulnerability is in Client-Based authentication. This isn't something that's used on your average https web server connection. Your typical https web server is just doing server-side authentication for TLS where the web server is presenting a certificate to the client and, as long as the client trusts that cert, the ongoing communication between the client and server are encrypted.

It's not that unique. Several recent OpenSSL releases have fixed client certificate authentication vulnerabilities, 1.0.2a and b if I recall correctly. They were only DoS vulnerabilities though, so not as severe. Client certificate authentication is also what happens every time a browser connects to an HTTPS server (it authenticates the servers certificate and certificate chain). This vulnerability makes it easier for an MITM to go unnoticed by the client/browser, because the MITM just needs a random, valid certificate tied to throwawaydomains.scam to issue an apparent genuine certificate for bankofamerica.com.

 

[seepy83]

It's not that unique. Several recent OpenSSL releases have fixed client certificate authentication vulnerabilities, 1.0.2a and b if I recall correctly. They were only DoS vulnerabilities though, so not as severe. Client certificate authentication is also what happens every time a browser connects to an HTTPS server (it authenticates the servers certificate and certificate chain). This vulnerability makes it easier for an MITM to go unnoticed by the client/browser, because the MITM just needs a random, valid certificate tied to throwawaydomains.scam to issue an apparent genuine certificate for bankofamerica.com.

This particular vulnerability is only against client side authentication, which usually is not implemented. It's not about breaking/forging the chain on the server side.

Yes, when a client connects to an HTTPS server, the client authenticates the server's certificate. But this vulnerability is against client authentication only, and it's not something that typically used outside of Internal/Enterprise ystems.

Edit: For reference, listen to the SecurityWeekly podcast from this past Thursday. They discuss it early on in the stories of the week: https://www.youtube.com/watch?v=ghLC-v8wR_w at the 3:38 mark.

 

[matricks]

I'll source the OpenSSL advisory instead:

During certificate verification, OpenSSL (starting from version 1.0.1n and
1.0.2b) will attempt to find an alternative certificate chain if the first
attempt to build such a chain fails. 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.

This issue will impact any application that verifies certificates including
SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication.

Not a lot of web browsers are linked against OpenSSL (some Linux desktop browsers), and Chromes BoringSSL fork was fixed prior to OpenSSL, but the general feature affected is involved in nearly all TLS sessions. No, not a lot of servers need patching, clients do, and not just enterprise clients.

 

[seepy83]

Well I know I'm not going to convince you. Everyone should just patch as necessary, but Client Authentication is where this vulnerability exists, and most public HTTPS web servers don't require client auth. Did you need to verify yourself with a CA (like verisign) and purchase a certificate to be able to browse Bank of America's website? No...because it doesn't require client authentication, only server side.

 

[seepy83]

https://cryptanalysis.eu/blog/2015/...icate-checks-in-openssl-1-0-2c-cve-2015-1793/

Another reference stating that Client Authentication is where the vulnerability exists.
Even the official advisory basically says that, but the wording is ambiguous.

 

[matricks]

Well I know I'm not going to convince you.

Likewise.

The OpenSSL announcement outlines two distinct scenarios that are vulnerable. I'll break it down:

This issue will impact any application that verifies certificates including SSL/TLS/DTLS clients

This is what I am talking about.

and SSL/TLS/DTLS servers using client authentication.

This is what you are talking about. I don't disagree that this scenario is real, what I am pointing out is that this latter scenario isn't the only scenario that is open to attack. For servers, yes, the latter scenario is the only scenario that matters. But to be useful, servers must have clients, and clients are affected (but there is nothing the server can do about that).

An HTTPS client performs certificate verification every time it connects to an HTTPS server (the first scenario). E.g. when you visit your online bank. If the client uses a vulnerable OpenSSL, it can be tricked to accept an invalid certificate for the bank.

The paragraph about how the attack works in your latest link is very accurate. The rest isn't.

Who is affected?
Probably [...]

Not very assuring.

Countermeasures

[...] Also, such scenarios with multiple paths for a single certificate might be avoided.

You don't get to choose how other handle their certificate. If someone wants to get their certificate signed by every trusted root CA on the planet, leading to multiple certificate paths, that's their choice. The only way to avoid it is to not use a service that uses a certificate signed by multiple roots. Suggesting this as a countermeasure shows a poor understanding of how certificates work. (Then again, it is written under the assumption that only servers authenticating their clients are affected.)

Some examples: wget is often used to download scripts and code on *NIX computers, the downloaded material may even be executed as root. It may use OpenSSL for TLS support (it also supports other libs). Curl has the same use, and is also used in library form by many client applications to perform various kinds of connections. It also supports OpenSSL for TLS support. In recommended configurations, both OpenVPN clients and servers are affected, since it does two-way certificate verification. The client verifies the server cert (same as a typical HTTPS web browser), and the server verifies the client cert (which is the part of this vulnerability everyone is able to grasp). However OpenVPN recommendations also suggests use of a shared secret in addition to certificate verification, which will mitigate the vulnerability in both cases.

OpenSSL Patches Critical Certificate Validation Vulnerability

The vulnerability allows an attacker with an untrusted TLS certificate to be treated as a certificate authority and spoof another website. Attackers can use this scenario to redirect traffic, set up man-in-the-middle attacks, phishing schemes and anything else that compromises supposedly encrypted traffic.

/r/sysadmin references:
Joking explanation
Very short explanation
More serious explanation

 

[seepy83]

matricks, I stand corrected. It took me a couple of days to verify, but I have confirmed that the vulnerability exists regardless of which side (server or client) is validating the certificate.

I was reiterating the assessment from sources that I generally trust as being knowledgeable when they speak authoritatively about a topic. I assumed when those statements were made, that they had reviewed the code changes and determined that the vulnerability only existed in a part of the code used for client auth. That is not the case.

 

[Red Squirrel]

Hmm this vulnerability does not sound as bad as heardbleed from sounds of it and I can probably re-enable SSL on my server, but I'll still patch of course once it comes out. It sounds more like it's a client side issue and not server. It's the server ones that are really bad because simply having a SSL related service running means someone can hack your server.

 

[matricks]

matricks, I stand corrected. It took me a couple of days to verify, but I have confirmed that the vulnerability exists regardless of which side (server or client) is validating the certificate.

As you already noted, many others made the same mistake. Maybe I had a bad case of this, I just get a bit eager when a vulnerability is misunderstood, in particular when its scope is underestimated.