Upgrade now: Older OpenSSL versions vulnerable to FREAK attack

The OpenSSL project shared the high-severity vulnerability privately in advance as part of a post-Heartbleed strategy for security disclosures

broken link breaching weakest link connection vulnerability 000004213740

The OpenSSL project revealed today that its namesake software, previously the source of the infamous Heartbleed data-leakage bug, was also vulnerable to the encryption-weakening FREAK attack. Older versions of OpenSSL should be upgraded immediately to the latest releases.

Unlike with Heartbleed, the OpenSSL Software Foundation shared details about the issue in advance with major operating system vendors, according to security researcher Brian Krebs, and kept details out of the public eye until after a patched version of OpenSSL was made available.

The original, tersely-worded announcement on the "openssl-announce" mailing list stated only that versions 0.9.8, 1.0.0, and 1.0.1, of the software were affected by a defect "classified as 'high' severity." (Version 1.0.2 wasn't listed as vulnerable, but an upgrade is recommended anyway.) But an OpenSSL Security Advisory document released earlier today described two "high severity" defects, CVE-2015-0291 and CVE-2015-0204.

The last of these is the FREAK attack, which allows a weaker set of encryption keys -- originally designed to conform to U.S. export restrictions on encryption in the 1990s -- to be substituted for current, stronger keys.

After news of Heartbleed broke, it became clear that some parties had earlier access to details about the flaw than others. Google did, and obviously OpenSSL itself, but many others -- Ubuntu, or Amazon Web Services, for instance -- weren't aware of the problem until after it had been made public. Worse, attempts by Red Hat to coordinate controlled disclosure with OpenSSL didn't work out.

In the wake of such a disorganized response, it's plain why OpenSSL's maintainers wanted to play things close to the chest up to the release, both as a general defensive measure and as a way to ensure the people most directly responsible for deploying OpenSSL at scale are clued in ahead of time.

But who that information deserves to be shared with ahead of time is an open question.

Adam Kujawa, head of Malware Intelligence at Malwarebytes Labs, noted in an email that limiting early disclosure to major organizations was a sensible way to protect as many people at once.

"Those organizations, if left unpatched, would create the largest group of vulnerable users and organizations -- all use one of the major operating systems on a daily basis," he said. "By releasing the patch to large organizations like Microsoft, there is little to no concern about the patch being handed out to potential cyber-criminals, who can target the vulnerability it addresses with new types of attacks."

Steve Hultquist, chief evangelist at security analytics firm RedSeal, noted that keeping things under wraps ahead of time served as a way to pre-emptively prevent automated exploitation of these vulnerabilities.

"Maintaining as much secrecy as possible is obviously critical for the integrity of the Internet," he wrote in an email. "It's a tough balance, especially knowing that automation is attacking OpenSSL constantly. The same advanced approaches using automation to attack networks and systems can be used to defend them."

Copyright © 2015 IDG Communications, Inc.

How to choose a low-code development platform