OpenSSL Vulnerabilities and the Ripple Effect

Most of you probably agree that open source is a great concept. Nearly anybody can take such code, modify it, and use it as they see fit. In many cases people even offer their changes back into the core code base from which the code was taken, which means everyone who downloads the code base will have the benefit of other people's changes. At the same time, that type of openness is a double-edged sword that can be quite dangerous.

A good case in point is the OpenSSL code used by the developers of the Debian OS. Back in mid-2006 someone made changes to the random number generator code in OpenSSL and then uploaded the changes into the unstable version of Debian that was in development at the time. That development code eventually became Debian Etch, which is the current stable release version of the OS.

The changes made to OpenSSL weakened its cryptographic strength and no one detected this problem until last week. So for about the past two years OpenSSL and other tools that rely on it have been vulnerable due to weak cryptographic keys. According to Debian's related security advisory, "Luciano Bello discovered that the random number generator in Debian's [OpenSSL] package is predictable. This is caused by an incorrect Debian-specific change to the [OpenSSL] package (CVE-2008-0166). As a result, cryptographic key material may be guessable."

Since the change was made to Debian-related code, any OS that is now based on Debian is probably affected by the vulnerability. The last time I checked there were well over a dozen Debian-based OSs, including the widely used Ubuntu, Knoppix, and Xandros platforms.

Complicating the matter further is the fact that there is another ripple effect to consider—it's not just Debian-based systems that might be affected by the vulnerability. If SSL keys were generated on a vulnerable system and those keys were then imported into some other OS, then those systems are affected too. And that's not all. Other encryption keys might be affected, including keys used for Secure Shell (SSH), Secure Sockets Layer/Transport Layer Security (SSL/TLS), OpenVPN, DNS Security Extensions (DNSSEC), and X.509 certificates.

That just about covers every mainstream encryption-related tool in use today! So the problem is not trivial and should not be taken lightly. As you might suspect, brute-force cracking attacks are now underway against SSH services (typically running on port 22 unless you moved SSH to some other port), and based on the information I've seen those attacks are on the rise (see the URL below). The current attacks typically involve dictionary-related username and password guessing.
isc.sans.org/portreport.html?sort=records

The solution is to upgrade your OpenSSL packages as well as any other packages based on OpenSSL, and then regenerate any weak keys. And, if you're a user of Debian or Ubuntu and you use 'apt' to perform updates then you'll find that the package installer will handle regenerating keys for you. Even so, double check your keys after upgrading. Be sure to check into the ssl-vulnkey tool that comes with the new 'ssh-server' package if you use SSH and perform an upgrade. It'll help you identify vulnerable SSH keys. There's also a Perl script available that can help you detect weak keys (see the first URL below). At the second URL below you'll find a method of automatically blocking hosts that attempt dictionary attacks on your SSH services. The latter method uses the DenyHosts tool at the third URL below.
lists.debian.org/debian-security-announce/2008/msg00152.html
www.howtoforge.com/preventing_ssh_dictionary_attacks_with_denyhosts
denyhosts.sourceforge.net

This particular vulnerability points out how one small code change can have a far-reaching ripple effect. In most cases changes are for the better. However, in this particular instance that's not the case. Obviously those who intend to take part in open-source code development need to be extra careful, especially when working with security-related code that is a core part of many other tools.