Two highly dangerous OpenSSL security bugs have been patched

OK, so neither of these two new, recently patched OpenSSL bugs come with a sexy code name like HeartBleed, Drown, or FREAK, but that doesn’t mean they’re not as serious as a server heart attack. Either one could wreck your security.

When OpenSSL works well it’s what often secures HTTPS. When it doesn’t, it’s a real security risk.

Stock Image: CNET

The OpenSSL cryptographic library is used to provide Secure-Socket Layer (SSL) and Transport Layer Security (TLS) in many popular web sites. These include Twitter, GitHub, Yahoo, Tumblr, Steam, and DropBox.

OpenSSL isn’t just used in web sites. OpenVPN, an open-source virtual private network, and older versions of the secure login and terminal program OpenSSH, use OpenSSL.

In short, if you’re running a secure server, chances are good you’re running OpenSSL and you’ll need to patch it today.

Here’s what you’re facing this time.

First, there’s a memory corruption problem with OpenSSL’s Abstract Syntax Notation One (ASN.1) encoder. This is a language independent formal data description notation.

The security problem arises from two smaller problems. The first of these is that the OpenSSL ASN.1 encoder can represent zero as a negative integer. That, in turn, can cause a buffer underflow with an out-of-bounds memory write. Since in the normal course of events negative zeros can’t be created that shouldn’t be a problem.

The real trouble arises because a second, independent bug revealed that the ASN.1 parser can misinterpret a large universal tag as a negative zero value. Large universal tags aren’t common but they are allowed in ASN.1.

Put these two together and an attacker can trigger an out-of-bounds write. This has been shown to corrupt memory and from there an attacker can start causing havoc.

In particular, according to the OpenSSL security blog, “Applications that parse and re-encode X.509 certificates are known to be vulnerable.” X.509 is used as the format for the public key certificates used for SSL and TLS. In other words, every time you connect with a secure web site, you’re using it.

In addition, “Applications that verify RSA signatures on X.509 certificates may also be vulnerable.” Because OpenSSL verifies the entire X.509 certificate chain from root to leaf, this would require successful attacks on valid certificates from trusted Certification Authorities. If those have been compromised, we’ve got bigger problems than this bug.

The other major OpenSSL hole that’s been patched this time around uses a padding oracle attack to decrypt traffic when the connection uses an Advanced Encryption Standard Cipher Algorithm in Cipher Block Chaining (AES CBC) cipher and the server supports AES-NI. A padding oracle attack works by introducing bogus “padding” data to an encrypted message. This makes the encryption easier to break. The truly obnoxious thing about this kind of attack is that if you break any encrypted message you can then break all the messages using the same encryption.

What happened in OpenSSL is that when a patch was made to fix an earlier problem, the Lucky 13 padding attack, the fix introduced a new problem. Specifically, it no longer checked that there was enough data to fill both the media access control (MAC) address and padding bytes. Whoops. This means that a Man-in-the-Middle attack can be used to decrypt data.

The solution to all these problems is to upgrade your OpenSSL as soon as possible. OpenSSL 1.0.2 users should upgrade to 1.0.2h, while OpenSSL 1.0.1 users should upgrade to 1.0.1t. These patches are now available from all major Linux distributors.