Security

Holes discovered in SSL certificate validation

A stinging indictment of the state of SSL client applications was recently published as part of the Proceedings from the ACM Computer and Communications Security (CCS) conference. The six authors of the paper (three each from Stanford and The University of Texas) describe testing that certainly should have been done as part of the application development process, but clearly wasn't. The problem stems partly from the libraries that provide SSL certificate verification, because developers are not using them properly. By and large the low-level library cryptographic protocol implementations are fine, the authors found, but the APIs are designed so poorly that developers commonly misuse them.

The paper [PDF] is entitled "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" and lives up to that label. It is truly an eye-opening read. The researchers simulated man-in-the-middle attacks using a combination of self-signed and invalid SSL certificates along with a valid certificate for the amusing AllYourSSLAreBelongTo.us domain to observe the effects on various applications. The observations led to the overall conclusion: "SSL certificate validation is completely broken in many critical software applications and libraries".

The researchers used Windows and Ubuntu laptops, a Nexus One smartphone, and an iPad 2 as clients for their testing. A second Ubuntu system running custom Java and C proxies, as well as the Fiddler web debugging proxy, served as the man in the middle. As they noted, the kind of attack that can be launched from the proxies is precisely what SSL is meant to thwart—their testing did not go beyond what an active man in the middle could do:

What they found was client applications that largely (or completely) accepted various kinds of invalid certificates and blindly sent private information (cookies, authentication information, credit card numbers) over an unsecured link. In many cases, the proxies could make the actual SSL connection to the remote server and funnel the data along—while surreptitiously storing the data away for (ab)use at a later time.

The paper gives plenty of examples of where the applications go wrong. Much of it can be blamed on bad library APIs, they said, in essentially all of the low-level SSL libraries (OpenSSL, GnuTLS, JSSE, CryptoAPI, etc.):

While that is certainly a problem, the application authors do bear some of the responsibility as well. It is not difficult to test an application against a few types of bad certificates. Because of the complexity of the APIs, developers should probably have been more wary that they might have made a mistake. Given that there is some kind of security requirement for the application (why use SSL otherwise?), it would seem prudent to verify proper functioning. Using a well-tested, industry-standard library is certainly an important piece of the puzzle, but there is more to it than just that.

There is also the problem of higher-level libraries perched atop OpenSSL, et al. The researchers found that libraries like Apache HttpClient, cURL, and the PHP and Python SSL libraries all had flaws in certificate validation. In fact, Python's urllib, urllib2, and httplib documentation warns that no certificate checking is done by the libraries, which evidently doesn't stop "high security" applications from still using them. One of the examples shows how this can all go awry:

These kinds of errors would almost be comical, if they weren't so serious. While it may sound difficult for attackers to position themselves "in the middle", the prevalence of wireless networking these days makes it easier. Taking over an access point (or just running a hostile one as "Free Airport WiFi", say) puts an attacker squarely in the middle. Users that are running the vulnerable applications over a link to a bad access point are susceptible to many kinds of attacks. Compromise of home routers is another possibility. Obviously, malware running upstream in the wired internet is equally dangerous (if harder to pull off).

The researchers conclude the article with recommendations for both application and SSL library developers. For the most part, they are pretty common-sense suggestions (do test your application, don't have multiple inconsistent error reporting mechanisms, etc.) that could certainly apply more widely than just SSL applications and libraries. Obviously, they could not test each and every non-browser SSL-using client (or even all of the SSL client libraries) out there, but the list of vulnerable components from the abstract is rather astonishing:

Perhaps the most distressing piece of this research is the appearance—at least—that developers are being pretty cavalier about checking the security baked into their supposedly "high security" applications. Beyond that, it is amazing that payment processors who are dealing with credit cards (and, importantly, credit card fraud) have seemingly not been very diligent about the code they distribute to their customers. All in all, this research shows that even "secure" applications and libraries often skimp on important verification testing—a seriously sad state of affairs.

Comments (28 posted)

Security quotes of the week

Comments (2 posted)

cgit: code execution

Comments (none posted)

dokuwiki: path disclosure

Comments (none posted)

drupal7: code execution

Comments (none posted)

exim4: arbitrary code execution

Comments (1 posted)

java: multiple unspecified vulnerabilities

Comments (none posted)

kdelibs: multiple vulnerabilities

Comments (none posted)

kernel: information leak

Comments (none posted)

libqt4: CRIME attack

Comments (none posted)

mozilla: multiple vulnerabilities

Comments (none posted)

optipng: use after free

Comments (none posted)

python-django: information disclosure

Comments (none posted)

request-tracker: multiple vulnerabilities

Comments (none posted)

rtfm: privilege escalation

Comments (none posted)