The most dangerous code in the world

An interesting paper you might like to have a look at: The most dangerous code in the world: validating SSL certificates in non-browser software.

Turns out there's a whole lot of busted stuff loose at the moment including a lot of eCommerce software (see abstract below). Trillian is also busted by the way.

Abstract:

SSL (Secure Sockets Layer) is the de facto standard for secure Internet communications. Security of SSL connections against an active network attacker depends on correctly validating public-key certificates presented when the connection is established. We demonstrate that SSL certificate validation is completely broken in many security-critical applications and libraries. Vulnerable software includes Amazon's EC2 Java library and all cloud clients based on it; Amazon's and PayPal's merchant SDKs responsible for transmitting payment details from e-commerce sites to payment gateways; integrated shopping carts such as osCommerce, ZenCart, Ubercart, and PrestaShop; AdMob code used by mobile websites; Chase mobile banking and several other Android apps and libraries; Java Web-services middleware - including Apache Axis, Axis 2, Codehaus XFire, and Pusher library for Android - and all applications employing this middleware. Any SSL connection from any of these programs is insecure against a man-in-the-middle attack. The root causes of these vulnerabilities are badly designed APIs of SSL implementations (such as JSSE, OpenSSL, and GnuTLS) and data-transport libraries (such as cURL) which present developers with a confusing array of settings and options. We analyze perils and pitfalls of SSL certificate validation in software based on these APIs and present our recommendations.

Hi Madfish,

the intro of the paper is very good to scare people into thinking there are vulnerabilities everywhere. I think that was the goal they had to push people to read the text

The article does note that it's not the SSL itself that is busted, but the way some higher-level libraries USE that SSL technology due to incomprehensible docs of the low-level tools that offer the SSL functionality.

Standard ImpressCMS doesn't use SSL, so a normal installation is not touched by this.

To use SSL, you need to do some extra setup, maybe we should look at the tools they propose on the page to see if there is a vulnerability.