It seems to be the software that we’re all relying on to protect our financial transactions and other critical network communications.
One of the main points of the first chapter of Learning Tree’s Cloud Security Essentials course is that it is very difficult to design and implement secure software. The course demonstrates this with a hands-on exercise in which we examine and test a flawed XML web authentication system.
Software libraries implementing SSL and its replacement TLS are far more complex, relied on for most Internet security, and totally broken. This is scary.
Researchers from Stanford University and the University of Texas show in their paper “The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software” that SSL certificate validation is completely broken in many security-critical applications and software libraries.
I wrote about the BEAST attack against SSL/TLS last year. That exploits a weakness in earlier protocol versions. But this recent paper shows that even when you start with a good protocol, the implementations may not follow it accurately. Or if they do, the resulting shared libraries may be used inappropriately because of incomplete documentation or confusing options.
They found that the APIs (or Application Programming Interfaces) of the SSL/TLS implementations which application programmers rely upon have confusing settings and options. These include OpenSSL, GnuTLS, and JSSE, plus data-transport libraries such as cURL. This leads to weaknesses in applications built on these libraries.
Amazon’s EC2 Java SDK is vulnerable, breaking the security of all cloud applications based on it. So are the software development kits which Amazon and PayPal on-line merchants use to transmit payment details. Integrated “shopping cart” applications relying on broken libraries include ZenCart, Ubercart, PrestaShop and osCommerce. Chase Bank’s mobile banking application and other Android apps are also vulnerable.
These poorly designed APIs confront programmers with confusing low-level interfaces. One example used in the paper is an Amazon PHP based payment library that attempts to secure a connection by setting cURL’s CURLOPT_SSL_VERIFYHOST parameter to true. That certainly looks reasonable! However, it should be set to 2. If a programmer sets it to true, that is non-zero and so it ends up being interpreted as 1 and that disables the verification!
Some popular API calls don’t even try to be secure. PHP’s fsockopen and Python’s urllib, urllib2 and httplib are popular with programmers, even though they establish SSL connections with no attempt at verifying the server’s identity.
The authors draw three main lessons from this mess. First, application software is not being rigorously tested. Second, many SSL libraries are unsafe by default, requiring the higher-level software to correctly set several somewhat misleadingly named options and correctly interpret return values. Error reporting is often indirect and easily overlooked. Third, even those SSL libraries that are safe by default tend to be misused by developers. They also conclude that SSL bugs tend to be buried in the middleware and hard to find.
As the authors say, the conventional advice is to use standard SSL libraries. “This advice is correct, but insufficient.”
Read the paper for all the details, it’s a well-written and sobering piece.