Still reeling from Heartbleed, OpenSSL suffers from crypto bypass flaw

Bug in crypto library strips away one of the Internet's most crucial protections.

A researcher has uncovered another severe vulnerability in the OpenSSL cryptographic library. It allows attackers to decrypt and modify Web, e-mail, and virtual private network traffic protected by the transport layer security (TLS) protocol, the Internet's most widely used method for encrypting traffic traveling between end users and servers.

The TLS bypass exploits work only when traffic is sent or received by a server running OpenSSL 1.0.1 and 1.0.2-beta1, maintainers of the open-source library warned in an advisory published Thursday. The advisory went on to say that servers running a version earlier than 1.0.1 should update as a precaution. The vulnerability has existed since the first release of OpenSSL, some 16 years ago. Library updates are available on the front page of the OpenSSL website. People who administer servers running OpenSSL should update as soon as possible.

The underlying vulnerability, formally cataloged as CVE-2014-0224, resides in the ChangeCipherSpec processing, according to an overview published Thursday by Lepidum, the software developer that discovered the flaw and reported it privately to OpenSSL. It makes it possible for attackers who can monitor a connection between an end user and server to force weak cryptographic keys on client devices. Attackers can then exploit those keys to decrypt the traffic or even modify the data before sending it to its intended destination.

"OpenSSL's ChangeCipherSpec processing has a serious vulnerability," the Lepidum advisory stated. "This vulnerability allows malicious intermediate nodes to intercept encrypted data and decrypt them while forcing SSL clients to use weak keys which are exposed to the malicious nodes. There are risks of tampering with the exploits on contents and authentication information over encrypted communication via web browsing, e-mail and VPN, when the software uses the affected version of OpenSSL."

Client devices are vulnerable no matter what older version of OpenSSL they are running. As stated earlier, servers are vulnerable when running 1.0.1 and 1.0.2-bata1, according to an accompanying OpenSSL advisory. The attacks are possible only when both sides are running a vulnerable OpenSSL version.

Further Reading

While serious, the latest OpenSSL flaw isn't as severe as the Heartbleed vulnerability that was disclosed eight weeks ago. That's because attacks exploiting the new vulnerability are harder to carry out and are generally less damaging. Whereas Heartbleed allowed anyone to send malicious packets that would force a vulnerable machine to divulge passwords, cryptographic keys, and other highly sensitive data, the latest attacks can only bypass encryption for a single targeted connection. And they can only be executed by people with some degree of control over the connection. Without doubt, that's serious, but not the catastrophe visited by Heartbleed.

"The good news is that these attacks need man-in-the-middle position against the victim and that non-OpenSSL clients (IE, Firefox, Chrome on Desktop and iOS, Safari etc) aren't affected," Adam Langley, a widely respected cryptographer and software engineer who works for Google, wrote in a technical analysis. "None the less, all OpenSSL users should be updating."

Separately, the OpenSSL advisory said that Thursday's updates fixed several other vulnerabilities that allowed attackers to remotely execute malicious code on servers or end user machines and crash devices. The most serious among them is a memory-corruption vulnerability in the OpenSSL implementation of the datagram transport layer security (DTLS) component and is cataloged as CVE-2014-0195. It was introduced by the same developer responsible for the Heartbleed bug. In addition to the previous previous link, Hewlett-Packard's Zero Day Initiative group has a separate blog post about the vulnerability here. A separate blog post from Symantec sheds additional light.

50 Reader Comments

I expect we will discover a lot of security vulnerabilities in the coming months in OpenSSL now that Heartbleed made a lot people aware of its sorry state. Atleast IT guys will get the routine of patching OpenSSL and rebooting every software that uses it

This just reinforces to me that everyone should be looking to move to LibreSSL as soon as feasibly possible.

I've been reading the commit comments over the past few days and it's just amazing the amount of stuff they're ripping out and fixing. I suppose proving how bad OpenSSL has become over the years and no-one really bothered to look.

I cannot stop laughing at all those people on this website who has downvoted my negative comments towards OpenSSL in general.

I will repeat the following: A serious look at OpenSSL needs to be done. The type of bugs that exist indicate a severe lack of understanding what the correct approach is when doing certain things. Using custom code to do something because there were performance problems on certain usage cases is a huge concern of mine.

The fact the length data going into a memory operation wasn't performed is a rookie mistake, its easily overlooked, hence the reason its a rookie mistake.

This just reinforces to me that everyone should be looking to move to LibreSSL as soon as feasibly possible.

I've been reading the commit comments over the past few days and it's just amazing the amount of stuff they're ripping out and fixing. I suppose proving how bad OpenSSL has become over the years and no-one really bothered to look.

At the very least a secondary fork should be created which sole focus is to backport any changes back into OpenSSL but leaving the stuff that is being taken out.

This just reinforces to me that everyone should be looking to move to LibreSSL as soon as feasibly possible.

I've been reading the commit comments over the past few days and it's just amazing the amount of stuff they're ripping out and fixing. I suppose proving how bad OpenSSL has become over the years and no-one really bothered to look.

Code changes mean almost nothing if they don't improve on the way they test and audit the code compared to OpenSSL. I hope they have plans to improve testing as well as the code.

This just reinforces to me that everyone should be looking to move to LibreSSL as soon as feasibly possible.

I've been reading the commit comments over the past few days and it's just amazing the amount of stuff they're ripping out and fixing. I suppose proving how bad OpenSSL has become over the years and no-one really bothered to look.

Code changes mean almost nothing if they don't improve on the way they test and audit the code compared to OpenSSL. I hope they have plans to improve testing as well as the code.

Given recent events.

I am pretty sure anything LibreSSL does in the future will be an improvement over what OpenSSL does.

I lately have come to wonder how many of this flaws are already known to the NSA and similar outfits from other nations. Perhaps this is why they are so butthurt over the Snowden leaks since they likely gave security researchers a hint or two on where and what to look for in terms of flaws and vulnerabilities.

This just reinforces to me that everyone should be looking to move to LibreSSL as soon as feasibly possible.

I've been reading the commit comments over the past few days and it's just amazing the amount of stuff they're ripping out and fixing. I suppose proving how bad OpenSSL has become over the years and no-one really bothered to look.

Code changes mean almost nothing if they don't improve on the way they test and audit the code compared to OpenSSL. I hope they have plans to improve testing as well as the code.

This is the main goal of what they're doing, though. By gutting out all the mysterious and barely used sections, they are improving the ability to read, maintain and audit the code base. And they're removing a LOT. Those commits contain very few fixes - it's mostly removing code that is either duplicated or for supporting things that already don't work in OpenSSL.

This just reinforces to me that everyone should be looking to move to LibreSSL as soon as feasibly possible.

I've been reading the commit comments over the past few days and it's just amazing the amount of stuff they're ripping out and fixing. I suppose proving how bad OpenSSL has become over the years and no-one really bothered to look.

At the very least a secondary fork should be created which sole focus is to backport any changes back into OpenSSL but leaving the stuff that is being taken out.

According to the site, LibreSSL will support multi-OS only after they get the right team in place AND have appropriate funding. Given the poor history of funding anything remotely associated with OpenBSD, I wouldn't hold my breath. Meanwhile, money is dumped into the black hole that is OpenSSL. http://arstechnica.com/information-tech ... evelopers/

This just reinforces to me that everyone should be looking to move to LibreSSL as soon as feasibly possible.

I've been reading the commit comments over the past few days and it's just amazing the amount of stuff they're ripping out and fixing. I suppose proving how bad OpenSSL has become over the years and no-one really bothered to look.

As soon as feasibly possible is some arbitrary date in the future where they might or might not actually support anything but OpenBSD (yes, I know they promised to if they can get funding).

Separately, the OpenSSL advisory said that Thursday's updates fixed several other vulnerabilities that allowed attackers to remotely execute malicious code on servers or end user machines and crash devices.

Separately, the OpenSSL advisory said that Thursday's updates fixed several other vulnerabilities that allowed attackers to remotely execute malicious code on servers or end user machines and crash devices.

A mere footnote, but perhaps more serious than the crypto issue.

What exactly makes them perhaps more serious than the crypto bypass flaw?

If one utilized Shodan to search for root access on Cisco routers across the internet, one might find that there are plenty of routers that are available for the taking. /just sayin'

I've seen someone log into a Cisco router randomly located via Shodan, dump the config and then analyze its location. It appeared to sit in front of a data center in the midwest. You know, one of those co-location facilities that exist all over the place these days? I'm sure they had biometric access to their ISO-whatever certified location....

So, yeah, its actually ridiculously easy to perform MitM attacks.

A buddy of mine worked for a large regional ISP. They had to deal with an employee who was using your typical corporate network tools (wireshark, etc) to watch the traffic between their customers.

While this attack may not be script kiddie friendly, no one should assume exploits of this attack will be rare.

OpenSSL devs appear to know the algorithms but not proper software engineering practices. I don't think funding the same development team is a good idea. LibreSSL, on the other hand, appears to know what they are doing, and they do have a good record of software practices.

Separately, the OpenSSL advisory said that Thursday's updates fixed several other vulnerabilities that allowed attackers to remotely execute malicious code on servers or end user machines and crash devices.

A mere footnote, but perhaps more serious than the crypto issue.

What exactly makes them perhaps more serious than the crypto bypass flaw?

Well, if being able to execute malicious code on servers means pulling their keys, that seems pretty bad.

Whereas the crypto bypass flaw apparently affects basically none of the popular browsers. Which doesn't mean it's not serious, because OpenSSL is used for more than just human-oriented HTTPS. But it doesn't seem "every server running OpenSSL can be owned" bad, if that's what the article is implying is possible.

I should have learned of this somewhere other than Ars but I found it on Ars. The links are great but including the CVE number in the text of the article would have been helpful for me.

Good point. I've added a link to CVE-2014-0224 in the third paragraph. I make it a point to include that information in articles, but occasionally I forget. Sorry. In the future, feel free to add the specific CVE number yourself in the comment you leave.

I should have learned of this somewhere other than Ars but I found it on Ars. The links are great but including the CVE number in the text of the article would have been helpful for me.

Good point. I've added a link to CVE-2014-0224 in the third paragraph. I make it a point to include that information in articles, but occasionally I forget. Sorry. In the future, feel free to add the specific CVE number yourself in the comment you leave.

Dear Mr.Goodin, I sense a bit of unnecessary snark in your comment. Forgivable, because your security articles are really good and useful to me. Thank you.

Thanks for the kind words about my work. They mean a lot.

I didn't intend any snark in my comment. Are you referring to my suggestion that people leave CVE numbers in comments when I forget? If so my intention is to improve communication, not to be rude or sarcastic.

According to the site, LibreSSL will support multi-OS only after they get the right team in place AND have appropriate funding. Given the poor history of funding anything remotely associated with OpenBSD, I wouldn't hold my breath. Meanwhile, money is dumped into the black hole that is OpenSSL. http://arstechnica.com/information-tech ... evelopers/

This just reinforces to me that everyone should be looking to move to LibreSSL as soon as feasibly possible.

I've been reading the commit comments over the past few days and it's just amazing the amount of stuff they're ripping out and fixing. I suppose proving how bad OpenSSL has become over the years and no-one really bothered to look.

At the very least a secondary fork should be created which sole focus is to backport any changes back into OpenSSL but leaving the stuff that is being taken out.

Such would largely defeat the purpose of using LibreSSL for its improved security, as the deletions are largely to make proper auditing easier and any functionality exclusive to OpenSSL will not face the same scrutiny. Even shared functionality on shared platforms will need to be carefully ported, as a lot of the OpenBSD-specific behaviors that LibreSSL relies on are undefined elsewhere. And that's assuming the OpenSSL people would want to cooperate at all.

The best analog I can think of for this situation is the EGCS fork of GCC. They bypassed the old development process to implement more drastic changes and improvement, and ended up the maintainers of the official GCC when it became clear that the fork was better. I imagine the same will happen with OpenSSL.

According to the site, LibreSSL will support multi-OS only after they get the right team in place AND have appropriate funding. Given the poor history of funding anything remotely associated with OpenBSD, I wouldn't hold my breath. Meanwhile, money is dumped into the black hole that is OpenSSL. http://arstechnica.com/information-tech ... evelopers/

OpenSSH has poor history? It's also maintained by the OpenBSD team

It has a poor history of funding. The software itself is excellent despite this.

This just reinforces to me that everyone should be looking to move to LibreSSL as soon as feasibly possible.

Not that this is bad advice on its own, but it is not at all helpful in this case - LibreSSL was just as vulnerable as OpenSSL was to the CCS bug. There will likely come a day when LibreSSL affords protection to an exploitable bug that OpenSSL is open to, but that day was not today.

This just reinforces to me that everyone should be looking to move to LibreSSL as soon as feasibly possible.

Not that this is bad advice on its own, but it is not at all helpful in this case - LibreSSL was just as vulnerable as OpenSSL was to the CCS bug. There will likely come a day when LibreSSL affords protection to an exploitable bug that OpenSSL is open to, but that day was not today.

It's only been a few weeks. I personally don't expect LibreSSL to have sufficiently differentiated itself from OpenSSL where it can be called trustworthy. Even testing the existing code is a challenge right now, and it was basically impossible a month ago. Give it a year and we'll see

This isn't an issue with just OpenSSL, but every single massively relied-upon but horribly under-funded OSS project. As sunlight finds a massive vulnerability and it gets fixed, and big players pony up money and/or start sifting through the code (finally), more will come out.

Much like big-name retailers finding that poorly investing in security and ignoring IDS alerts ends up nearly costing the farm.

The tl;dr?

People are waking the hell up about security, and finding themselves woefully unprepared, underfunded, and naked.

the good news is that the main programmers are be being paid (a living wage) to fix the open SSL bugs... The bad news is that open SSL. has bugs ... the good news is that they will be fixed.

A lot like having to fix the fancy deadbolt on your door (and thus needing it to be removed) and having to rely on the standard door lock protection... meaning ultimately in the near future (the deadbolt)/ open SSL will be bulletproof...

Separately, the OpenSSL advisory said that Thursday's updates fixed several other vulnerabilities that allowed attackers to remotely execute malicious code on servers or end user machines and crash devices.

A mere footnote, but perhaps more serious than the crypto issue.

What exactly makes them perhaps more serious than the crypto bypass flaw?

If true, "executing malicious code" on the server especially seems like quite the danger.

I should have learned of this somewhere other than Ars but I found it on Ars. The links are great but including the CVE number in the text of the article would have been helpful for me.

Good point. I've added a link to CVE-2014-0224 in the third paragraph. I make it a point to include that information in articles, but occasionally I forget. Sorry. In the future, feel free to add the specific CVE number yourself in the comment you leave.

Separately, the OpenSSL advisory said that Thursday's updates fixed several other vulnerabilities that allowed attackers to remotely execute malicious code on servers or end user machines and crash devices.

A mere footnote, but perhaps more serious than the crypto issue.

What exactly makes them perhaps more serious than the crypto bypass flaw?

If true, "executing malicious code" on the server especially seems like quite the danger.

I'm wondering about that bit myself. The ability to execute malicious code implies the ability to instruct a server (or end user machine) to do almost anything. Couldn't a flaw like that be (or have been) used to deliver any number of malicious payloads in any number of different ways (from turning the server into a zombie spambot to injecting malicious scripts into all web pages served ... to almost anything else one can imagine)?

I must be missing something ... was there information in the release that mitigates the scope of exposure to the point where the exploit potential was trivialized to being academic?

Really, what this fiasco illustrates that if you slap the word "open" on to a project name and give it a FOSS license, people and companies may just assume that it is well written and being maintained by competent people.

"The TLS bypass exploits work only when traffic is sent or received by a server running OpenSSL 1.0.1 and 1.0.2-beta1…The vulnerability has existed since the first release of OpenSSL, some 16 years ago."

"Client devices are vulnerable no matter what older version of OpenSSL they are running…The attacks are possible only when both sides are running a vulnerable OpenSSL version."