New SSL Vulnerability

It’s hard for me to get too worked up about this vulnerability:

Many popular applications, HTTP(S) and WebSocket transport libraries, and SOAP and REST Web-services middleware use SSL/TLS libraries incorrectly, breaking or disabling certificate validation. Their SSL and TLS connections are not authenticated, thus they—and any software using them—are completely insecure against a man-in-the-middle attacker.

Great research, and—yes—the vulnerability should be fixed, but it doesn’t feel like a crisis issue.

Another article.

Tags: ,

Posted on November 7, 2012 at 1:39 PM • 22 Comments

Comments

DrNo • November 7, 2012 1:56 PM

Yes it’s a vulnerability and yes it’s SSL-related, but it’s as much an SSL/TLS vulnerability as drunk-driving is a defect in the car design.

Henning Makholm • November 7, 2012 3:09 PM

Perhaps I read the article too quickly, but it would be nice to know how many pieces of software the authors had to sift in order to find the vulnerabilities they burn.

Each of them is crisis-worthy enough on the level of THAT PARTICULAR PRODUCT (though ones where the vulnerable client code runs on servers only, such as the payment-gateway PHP module, are going to be out of reach for ordinary opportunistic crook anyway).

But whether the alarmist spin about the internet in general crashing and burning is even slightly warranted depends a lot on whether it is 5% or 95% of all non-browser applications that are vulnerable.

Dave • November 7, 2012 3:12 PM

Yes, there’s no reason for cryptographers to get worked up, but it’s terrible for implementers and users of these systems, and it’s endemic of the attitude that creates vulnerable software. MitM is not always a practical attack to perform, but with the widespread ignorance on proper certificate validation I would not be surprised to hear of instances in which MitM attacks on these systems are both easy to perform and devastating. These vulnerabilities would be inexcusable on the web, so IMHO they are inexcusable in other internet applications too.

Henning Makholm • November 7, 2012 3:30 PM

The article closes with recommendations targeted at developers of applications and libraries. I think it ought it ought to be supplemented with:

For developers of web-accessible APIs

If your service is available over HTTPS (or another TLS-based protocol), have publicly available test servers that provide a fully functional (at least at the protocol level) mock-up of your service, except that they present self-signed certificates and/or certificates for the wrong domains. In your API documentation, encourage application developers to test their finished code against these servers to verify that the clients properly refuses them.

Providing a test server which presents a certificate for the wrong domain would be as simple as making a DNS alias pointing to the production servers from a different name. One with a self-signed certificate would probably need a spare IP (or a non-standard port).

Christian • November 7, 2012 3:55 PM

Its not even a bad use of crypto.

I have done the same.
Reasoning behind it: The attacker model is to listen only/not change anything in the traffic.

Its only a vulnerability/lack of security if you have a stronger attacker model.

Adam • November 7, 2012 4:22 PM

It sure seems like most “security issues” that people find in applications recently are a lack of correctly performed certificate validation. I am not at all surprised by this issue but I don’t think it’s anything particularly novel.

Henning Makholm • November 7, 2012 5:54 PM

@Christian: Where in the contemporary internet would you find an attacker with a technical opportunity to eavesdrop on TCP conversations, but not to change the traffic? That seems to require very special-case scenarios, much more exotic than subverting a piece of the routing infrastructure or simply joining a shared medium such as a WLAN.

Dan Goodin • November 7, 2012 6:08 PM

Bruce, I’m surprised to read you downplaying the severity of the defects these researchers uncovered. These were widely used apps, including Trillian, AIM and a mobile smartphone app from Chase Bank, that established encrypted connections even when presented with fraudulent SSL certificates.

For more, please see the article I wrote for Ars Technica at:

http://arstechnica.com/security/2012/10/faulty-ssl-fooled-by-phony-certificates/

Anyone using one of these apps on an open network is wide open to the very types of attacks SSL is designed to prevent.

Why isn’t that serious?

Regards,

Dan Goodin

Kevin McArthur • November 7, 2012 6:34 PM

Seeing as I’m cited in this paper, thought I’d share that this vulnerability affects a number of major credit card processing companies and affects a lot more than is disclosed in the academic paper.

I’ve been working on this for well over a year with the Canadian Cyber Incident Response Centre.

You can read more about this at http://www.unrest.ca/peerjacking and http://www.unrest.ca/responsible-disclosure-and-the-academy for a little background on this paper.

Dirk Praet • November 7, 2012 6:57 PM

I read this as just another instance of code writers having insufficient knowledge of a protocol/mechanism to implement it correctly, instead blindly relying on an API that allows them to do stuff the wrong way. A classic case of full-proof vs. fool-proof. Not to mention failure of testing and code review processes for those apps affected.

Buck • November 7, 2012 8:13 PM

I think that the defect in OpenSSL usability, at
least, has been known for a while. See

http://www.peereboom.us/assl/assl/html/openssl.html

There’s an O’Reilly book on OpenSSL, too, but
the impression i have of that was that i was left
thoroughly befuddled by the arcane configuration-
file mechanism, so i don’t remember how well it
made sense of the APIs or pointed out the pit-
falls

Section9Bateau • November 7, 2012 11:58 PM

This vulnerability is far from new, I was marking this as a finding quite regularly in my audits several years ago against applications I tested, even just found another case of it yesterday. I think this was in one of the first OWASP top-10s.

Ahh, yes, A9 from 2007, and again, A9 from 2010, etc.

No Dummy, But Not An SSL Expert • November 8, 2012 12:58 AM

As a very senior programmer recently introduced to programming with OpenSSL, I have to wholeheartedly agree with the paper’s complaints about usability. I expected that a state-of-the-art library would make it easy to do the right thing and hard to do the wrong thing, but the exact opposite is true: unless you do everything exactly right and write a (relatively) lot of code, you end up with an insecure connection. I don’t want to be writing code that is critical to the security of the connection – I want the library to do that, since people who really understand the issues have reviewed it.

Clive Robinson • November 8, 2012 7:02 AM

@ Dan Goodin,

Bruce, I’m surprised to read you downplaying the severity of the defects these researchers uncovered.

I don’t think Bruce is within the context of this blog.

It is just one of many hundreds of similar “human errors” that occure with developers just about every day of the week. Which is why Bruce has in all likelihood said,

“It’s hard for me to get too worked up about this vulnerability“

As others have noted it’s not technically even an SSL issue but a more general “user issue” for developers implementing security applications.

To explain the difference,

You go out to your car get in put the key in the ignition and turn it and the car does not start.

If asked you would in all probability say “my car is broken down” which whilst it is true is unhelpful and in all likely hood incorrect technicaly.

What has happened is some small ancillary part of the car which actually does not prevent it being driven has let you down, such as the battery is flat (because you left the lights on) or the lock or switch mechanism has broken or come out of alignment (possibly due of you using excessive force) or a fuse has blown because you have drawn to much current from cold due to say using the cigarette lighter having the radio on loud and a seat warmer whilst trying to turn the engine over. It could also be that the solonoid that switches the high current to the starter motor has worked lose or become broken or the starter motor has stoped in a position it cannot start from so appears seized, neither of which is in use when the engine is running and the car is being driven by you.

Thus the probability is if the engine is turned over in some way (as used to happen with starter handles or when you jump a dead battery, or put a non auto into first gear and push start it) then the car would be quite drivable as long as you did not stop the engine.

So when to you your car won’t start you say your car is broken with the incorrect implicit assumption it is not usable for it’s primary purpose. A motor technician however knows that the car is in all probability functional for it’s primary purpose it just needs either the circuit compleating or the starter motor unjamming or the battery jumping or a push start for you to drive it away.

Thirty years ago push starting, battery jumping and hand cranking were well known and many motorists new about them. These days however due to much additional complexity and increased reliability many drivers do not have any knowledge of such things.

And that’s the point from a technical asspect this issue is the user (ie program developer) not knowing what to do when using the code library. And from this asspect it is so common it is very difficult to get worked up about.

However for a limited set of end users it might be a problem now but for most no. In a few days time a month or so or even a year or two it might not be a problem for the majority of end users. But I would expect the problem now it is known to become fixed in the next code release.

And this brings up another “user issue” within the accepted “custom and practice” user model. Unlike PC’s with patch Tuesday and Auto Updates smart phones due in the main to the connectivity service providers and their charging models get neither patches or upgrades.

So your view point of it potentialy being a serious concern for end users is valid but misplaced for this blog. Because you have to also accept that from the technical view point it’s just one more fairly yawn worthy human error amongst hundreds and from that respect would not normaly even make it onto this technical blog because there are other blogs (Krebs being just one of many) that do cater predominantly for the end user with patch/update alerts.

It is only that it does have some potential security asspects that Bruce has Bloged on it and has said,

“Great research, and — yes — the vulnerability should be fixed, but it doesn’t feel like a crisis issue“

Which from a purely technical perspective is correct.

It should be the job of journalists and blog writers who cater specificaly to application developers who should be giving a heads up to their readers.

And in a little while it will be your job amongst many other more “end user focused” journalists and blog writers to make the end user aware that they realy should upgrade once each individual vulnerable package has been fixed and chase the developers if you think they are being to slow.

As in humour timing is very important in security,shouting loud now to end users before the developers have fixed an application or have had reasonable time to fix an application is actually going to be counter productive, in that they will hear you, find they cannot do anything and just ignore it in future when the patched application is available….

Nathar Leichoz • November 8, 2012 7:26 AM

Not a vulnerability with SSL. Just individual applications not checking whether the certs are valid or not.

Dan Goodin • November 8, 2012 8:55 AM

@Clive Robinson

It’s immaterial whether this is new or old, or caused by an error in SSL or the way sloppy programmers implement SSL.

What matters is that a statistically significant percentage of apps have a gaping security hole that can get dissidents in rogue nations killed and wipe out the bank accounts of people in developed nations.

I still don’t understand why that’s not worth getting worked up about.

Richard Moore • November 8, 2012 11:18 AM

One of the causes of the poor usage of ssl is that the documentation for openssl is frankly awful. It also doesn’t help that openssl doesn’t provide any APIs to implement RFC 2818 compliant hostname matching. On the other hand, these papers have been quite useful to me in writing a presentation on how to avoid coding exactly these kind errors when using Qt!

Trench Coder • December 18, 2012 11:48 PM

The real problem with SSL is certificate management. SSL is not broken, beyond its encryption vulnerabilities, and the available APIs generally work, confusing or not, barring the usual bugs. Current SSL applications are written the way they are because there simply is no standard way to manage certificates. As an application vendor, you cannot install/uninstall certs everywhere you need to, and you cannot rely on users to do it for you, and you cannot do without SSL support. What to do? Implement SSL support but ignore certificates. This is a business decision, and it will continue to be made this way, unless a standard is adopted for certificate management that doesn’t require users to do anything other than click OK.

HK • May 4, 2013 5:14 PM

Seems like everyone agrees:
a. This is not an SSL/TLS vulnerability
b. This is an issue with application implementation
c. From an SSL library perspective, some of them could be more user friendly with comprehensive documentation to help developers understand the API options better

However, all said and done, any protocol/tool is only as effective as the user using it.

I think the point about certificate management is an interesting one! Certificate management standards would definitely pave a way for app providers who forgo certificate validations just because they do not have a simple way of deploying/managing certs.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.