OpenSSL Security Advisory | Hacker News Reader

OpenSSL Security Advisory

openssl.org

385 pointsdavidroetzel84 comments

CVE-2014-0224 looks the worst of this bunch.

It seems openssl will accept ChangeCipherSpec messages much too early. CCS in TLS means "we've finished handshake/renegotiation and will now start using the new keys".

It looks likely that a MITM can send CCS to both ends during handshake, and have them agree on the empty master secret (and therefore trivial application data encryption keys). This is pretty bad as far as TLS bugs go (as bad as "goto fail", but not as bad as "heartbleed").

Given that accepting TLS messages only within the right constraints is fundamental to correctness of TLS and openssl seemingly can't get this right (this, and heartbeat messages before/during handshake), it seems likely this isn't the last problem of this kind.

as bad as "goto fail", but not as bad as "heartbleed"

Thank you for this excellent description for we who recognise this must be a problem, but lack the area knowledge to immediately appreciate how bad (or not) it may be.

I would even dispute it being as bad as goto fail. For this to work both client and server must be vulnerable and the attacker must be in a privileged network position. A malicious server can do it, but it's significantly more difficult to exploit this than goto fail.

Edit: agl has a good writeup of the bug and what it might take to exploit https://www.imperialviolet.org/2014/06/05/earlyccs.html

It would mean (for example) that your local coffee shop could MITM their clients connecting to the bank through their free wifi. Being in a privileged network position isn't that hard, with all the mobile devices flying around everywhere.

That would be mostly limited to Konqueror (does anybody still use that?) and Google Chrome on Android.

Which other browsers use OpenSSL?

I'm not claiming that being in a position to MITM is super difficult, but in your given example it's unlikely that you'd be vulnerable since web browsers (outside of Chrome on Android) don't use OpenSSL. Additionally, there is a degree of sophistication required to attempt this attack that exceeds that of goto fail. So again, bad, but not as bad as goto fail.

Completely unscientific observation: More people in my local coffee shop are using phones than laptops, and more of those phones are Androids than iOS. I know anecdotally that the Chrome browser is very popular on Android. I would give even odds on there being more people to exploit with this than there were with goto fail.

I use coffee shop WiFi when I access useless sites such as Drudge Report. However, it's not hard to either

a) switch to cellular on a phone before accessing something important like a banking site

or b) use something like Personal Hotspot together with a phone switched to cellular to allow a laptop to access something important like a banking site

That's what I do. I certainly don't trust random WiFi for sensitive communications.

IMO you're much safer relying on AT&T or Verizon to connect you to key sites via cellular service rather than thru WiFi. OTOH I know that in the past AT&T has automatically switched my iPad from cellular to WiFi when I was at a coffee shop that had service from them. So this may be a little tricky in practice.

Even worse, from what I've observed, such networks are often not secure even against a trivial ARP spoof attack, so anyone connecting to the coffee shop Wi-Fi could mount this attack.

Is there any reasonable way to make them secure against ARP spoofing? As I understand it, it would require individual login from all clients (some form of 802.1x)?

And even if you do protect against ARP spoofing via 802.1x -- you would still need some kind of shared secret/certificate scheme to avoid a fake access point? As anyone sitting next to you is likely to be able to provide a stronger signal than the hotspot...

Reminds me that I had an idea to wrap up some kind of hot-spot with an easy to use internet cafe style time-limited access software distribution and offer up to local businesses... I suppose these days providing a screen for qr-code sharing of details would be a viable option...

To make them immune to the ARP spoofing in the general case is hard, but as I understand it, to make them immune to the specific case of clients other than the gateway impersonating the gateway (which is what people want to do for most MitM) is pretty straightforward. The access point is probably itself the gateway most of the time, so it knows the gateway's MAC (its own), and it can reliably refuse to forward ARP packets for other MACs claiming to be the gateway.

> it can reliably refuse to forward ARP packets for other MACs claiming to be the gateway.

I thought most wireless lans acted as an (shared medium) ethernet, that is, they allow clients to send packets directly client to client? That is, I thought [ed:naughty]-client could just broadcast ARP packets directly to the clients? Or does perhaps (ethernet) broadcast traffic go through the gateway?

None of this helps with a rouge AP, of course -- so it might be a bit academic.

In infrastructure mode, all WiFi traffic goes through the access point. Whether or not, from a configuration perspective, the access point lets you meddle with traffic that passes through it is a separate question, but I don't think there's anything wireless-protocol-wise that precludes it.

Just to add—in open networks masquerading as the AP is possible so long as you can reach the hosts with your Tx. This is mitigated with encryption, however, as I understand the WPA2 standard, I suppose you could send out a broadcast ARP response packet encrypted using the Group Transient Key pretending to be the AP. However, probably all sane clients would discard ARP responses that were broadcast, as normally, ARP responses should always be unicast to the requesting client.

Edit: Looks like I was spot-on! This is a real vulnerability, and is called Hole 196: http://www.airtightnetworks.com/wpa2-hole196.

How does a client actually authenticate a packet coming from the AP versus something else? The only info is a preshared key so it doesn't seem possible to have any true security there.

I believe the AP has separate session keys per client (the shared secret is used for authenticating with the AP and setting up a session -- and yes, I guess that means if you know the shared secret the client expects you to use (eg: a note in a cafe) you can probably impersonate the AP at the point of client association) -- but the group key is special.

But as demonstrated up-thread I clearly need to refresh my knowledge of 802.11*...

The PSK is used to derive pairwise keys between each station and the AP. However, if the attacker knows the PSK, it's theoretically impossible sufficiently advanced attacks. That's why enterprise networks use RADIUS for enhanced security.

(side-reply as direct reply is either in cool-down or limited due to depth)

Interesting, I hadn't really looked into 802.11alphabetsoup in terms of ad-hoc vs infrastructure -- wasn't aware the ap was a bottleneck. The natural next question is if there are any standard secure forms for ad-hoc networking?

It would seem that shared-secret should be easy enough (but probably with the same/similar security issues as other shared-media networks in addition to the possibility of guessing the key). Some form of certificate authentication, or kerberos like shared-secret-trusted-mediator should be possible? But having a look around, I can't seem to find any - certainly not any that could be expected to work with standard OSs and devices...?

I suppose one could simply use an unsecured ad-hoc network + vpn for routing? Still I don't know of any VPN-styles that would allow broadcast traffic over such a mesh network?

[edit: It would appear the olpc projects has done some work in this area: http://wiki.laptop.org/go/Mesh_Security

ed2, also: http://wiki.laptop.org/go/Mesh_Network_Details

And: https://github.com/cozybit/open80211s/wiki/HOWTO ]

You're right. I was mainly talking about the impact of exploitation, rather than the conditions necessary for it.

Privileged network positions are sort of a joke with the current state of wifi security.

Note also that this type of failure to strictly adhere to spec behaviour, for any specific case, is perfectly possible in other implementations, whereas coding errors like goto fail or heartbleed are much less likely to duplicate in different codebases. Thus, I wouldn't rule out other SSL implementations being vulnerable to this exact issue as well.

Was the person who commited ChangeCipherSpec the same person who commited HeartBleed?

Nop => http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Inject...

Since most(1) web browsers do not use OpenSSL, CVE-2014-0224 is not going to be a big concern for people browsing using SSL, but it is a concern for machine-to-machine communication where using OpenSSL on both ends will be common.

Given that this also affects 0.9.8 there are going to be lots of backend systems that need upgrading.

(1) Apparently Chrome on Android is the odd man out in using OpenSSL, but I don't know if it is vulnerable to this problem.

This should be interesting for OpenVPN.

I think people underestimate how many products use OpenSSL...

http://www.pcworld.com/article/2143440/server-makers-rushing... http://www.networkworld.com/article/2176022/router/heartblee...

It sounds kind of stupid, but i'm thinking the best short-term way to secure an exposed OpenVPN tunnel against future OpenSSL TLS holes may be two layers of encrypted traffic. One static key tunnel to prevent public TLS holes from exposing the installation, and inside that a strong TLS 1.2 implementation with perfect forward secrecy. It's lame and limited (due to the requirement on the static key) but could work for black-box implementations where you don't have much choice in your use of the product. Some cheap hacks to the source of OpenVPN may even allow both of these to be stacked without requiring two tunnels.

OpenVPN already sort of supports this: https://community.openvpn.net/openvpn/wiki/Hardening#Useof--...

While it does not provide additional encryption, it does prevent clients who do not know the secret from initiating connections (and thus interacting with the TLS state machine/etc).

You don't need another layer of encryption, just another layer of authentication protects you from attacks that require an active mitm adversary (as basically all attacks on TLS do).

OpenVPN has offered such an option for a long time: https://community.openvpn.net/openvpn/wiki/Hardening#Useof--...

This wraps just the TLS control channel, which has low traffic and thus results in a small overhead. The data channel is separated from TLS in OpenVPN, which is why TLS-auth does not add overhead to the actual network packet encapsulation. TLS-auth is a neat feature and everybody should use it.

Since tls-auth merely creates an HMAC around all the TLS message types, it makes me wonder if there's still an aspect of initiating a TLS connection (or flaws in the HMAC generation?) that could leave tls-auth vulnerable to future TLS-related flaws. But that could be excessive paranoia.

I think that whether tls-auth protects you against CCS Injection will hinge not on the HMAC but on tls-auth's replay protection. An attacker can always replay a previously-sniffed CCS packet with a valid HMAC, so it all comes down to whether that replay will be properly discarded.

tls-auth does prevent replays: note the "packet-id for replay protection" at http://openvpn.net/index.php/open-source/documentation/secur....

OpenVPN does a pretty good job, as long as you choose a sane configuration (most importantly, use tls-auth and TLS key negotiation). It's definitely less vulnerable than other TLS stuff due to the tls-auth option.

(Full disclosure: my company provides the hardened OpenVPN-NL, and I've done a little work on that.)

CVE-2014-0224 is the only one that really impacts OpenVPN (No DTLS nor SSL_RELEASE_BUFFERS etc) and as others have said, if you are using OpenVPN chances are you are making use of TLS-AUTH which helps mitigate MITM issues to a reasonable degree. Furthermore, both sides apparently need to be vulnerable. So if you have little control over the clients, updating the server seems to be adequate to address this specific bug.

If I'm understanding the CVE correctly, it has nothing to do with the browser. It's when it's on the Server, an attacker could just make OpenSSL think their "browser" doesn't support all of the good algo's and eventually cycle through it's available algo's until a relatively insecure one is decided upon (like the relatively weak CBC algo's).

So, it is a potential threat to servers since most web server are *nix based and most of those will have the default of OpenSSL installed.

However, I seem to recall this always being a possible attack vector, in any SSL/TLS library due to how browsers/servers have always negotiated which algo to use based on which are commonly supported and the strongest available... so ... nothing new?

Adam Langley at Google has a good technical description here: https://www.imperialviolet.org/2014/06/05/earlyccs.html

Specifically,

    With any OpenSSL client talking to an OpenSSL 1.0.1 
    server, an attacker can inject CCS messages to fixate the 
    bad keys at both ends but the Finished hashes will still 
    line up. So it's possible for the attacker to decrypt    
    and/or hijack the connection completely.

Is libcurl affected by CVE-2014-0224?

Logos are now prerequisite, so of course CVE-2014-0224 has you covered. http://ccsinjection.lepidum.co.jp

If you want to see the patches they're now up on GitHub:

OpenSSL 1.0.1: https://github.com/openssl/openssl/commits/OpenSSL_1_0_1-sta...

OpenSSL 1.0.0: https://github.com/openssl/openssl/commits/OpenSSL_1_0_0-sta...

OpenSSL 0.9.8: https://github.com/openssl/openssl/commits/OpenSSL_0_9_8-sta...

"Q. How did you find this bug?

A. This bug was discovered by Masashi Kikuchi of Lepidum. He found this bug while studying safe TLS implementations using a proof assistant system Coq."

So they are starting to find actual bugs with Coq? I'm impressed, and would love to know if anybody has more details (lepidum's blog seems down at the moment).

The ImperialViolet post linked above gives a different URL for the blog post which does work: http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Inject...

There's some good discussion of it on the netsec subreddit.

http://www.reddit.com/r/netsec/comments/27dhcn/openssl_secur...

The large volume of vulnerabilities coming out of OpenSSL are worrying, but it likely reflects the increased effort being put into auditing and fuzzing the code after Heartbleed. What is more worrying is the many other critical pieces of software that have nowhere near the level of scrutiny that OpenSSL is receiving currently.

Yes, the current situation is (probably) bad.

The Core Infrastructure Initiative is starting to address that: http://www.linuxfoundation.org/programs/core-infrastructure-...

Searching for vulnerabilities is just like mining for gold: you go for the richest veins first and OpenSSL is deployed widely enough and in enough places where it really matters that it is currently a priority item.

I guess until a couple of weeks ago OpenSSL was 'one of many other critical pieces of software that have nowhere near the level of scrutiny that WordPress (and I know you don't meant Wordpress) is receiving currently'. So we'll see a re-focusing on other software when people feel that either the OpenSSL well of exploits has at least temporarily dried up or when something else that is crucial breaks.

But as long as vulnerabilities in OpenSSL are discovered at this rate it seems to be an effort well-spent, and we will all reap the benefit of that effort.

Heartbleed really shook the IT world, I don't know anybody in operations that was not affected by it. (And I can hear them collectively sighing right now). If there was a Richter scale for exploits it would have rated a '9'.

It's a bit like the news cycle, these things tend to burn out. But right now OpenSSL exploits are very much in the spotlight, and guarantee almost instant fame for the person discovering one. So I think we'll see a few more of these before it will quiet down. (I actually hope that we won't see more of these but given the past couple of weeks that hope is not very realistic).

> Heartbleed really shook the IT world, I don't know anybody in operations that was not affected by it. (And I can hear them collectively sighing right now). If there was a Richter scale for exploits it would have rated a '9'.

Having been around in the '90s, with the instant root shell exploits and whatnot, I tend to think of Heartbleed as more of a 6.

I think some people have also forgotten what a complete disaster Microsoft was right up until the mid 2000s. IE exploits, Windows exploits, IIS exploits (remember Code Red?). They well and truly earned their reputation.

Teardrop was fantastic.

There's also a linux kernel update today, for a local root exploit(?) (CVE-2014-3153):

https://lists.debian.org/debian-security-announce/2014/msg00... https://news.ycombinator.com/item?id=7851535

Debian advisory: https://lists.debian.org/debian-security-announce/2014/msg00...

Red Hat 6 advisory: https://rhn.redhat.com/errata/RHSA-2014-0625.html

Red Hat 5 advisory: https://rhn.redhat.com/errata/RHSA-2014-0624.html

Ubuntu advisory: https://lists.ubuntu.com/archives/ubuntu-security-announce/2...

And FreeBSD

http://www.freebsd.org/security/advisories/FreeBSD-SA-14:14....

Anybody know what the difference is between Ubuntu package

openssl 1.0.1e-3ubuntu1.2 and openssl 1.0.1e-3ubuntu1.4

1.0.1e-3ubuntu1.2 is older and doesn't have the fix for this CVE.

This page [1] links to the package's changelog [2], which should answer your question.

[1]: http://packages.ubuntu.com/saucy/openssl

[2]: http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/...

Interested to see if LibreSSL has knocked these ones on the head.

Two of them, CVE-2014-0198 and CVE-2010-5298. We haven't even started looking at the protocol code.

I'll also note that "This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common." is pretty misleading. nginx is affected, is not multithreaded, but is fairly common.

Thanks for the reply. This is exactly why I have more faith in you guys with LibreSSL. You're right on the case, know what's going on all the time and communications are good (as they always are with the OpenBSD project). Please keep up the great work.

Happy to see you guys working on this. Is there a way to specify that donations should go to the LibreSSL effort rather than to the OpenBSD foundation as a whole?

That is a weird request to me. Telling that it should go to the LibreSSL effort is very much like telling OpenBSD developers what they should work on. The way I understood it, most OpenBSD developers are not for hire, not in a manner like this anyhow. These people work on the things they want to work on, and they share the result of their work as a gift to the world. Donations are a gift in return, and the funding enables them to hack more (i.e. hackathons, hardware for developers who need it, infra, etc.) and to share the result with the rest of us (servers & infra).

Can you imagine someone saying "I want to give you this gift but only if you focus on thing X (which I care about) and not on things Y and Z (which you care about)"?

Keep in mind that the BSDs strive to be a complete, integrated operating system. While some devs focus on small parts of the tree, many or most work on the larger whole. Improvements to specific parts are a part of improvements to the whole. Working on LibreSSL is a byproduct or part of working on OpenBSD.

Can you buy a faster server and more bandwidth to serve this one subdirectory in your project? But don't spend that money on anything else?

EDIT: Having said that, developers are and have been funded to work on specific things.. IIRC the kms work was sponsored, and gilles works on smtpd as a part of his job. But I think it would be kind of rude to disregard the effort the core OpenBSD devs have spent on LibreSSL and only donate if you can give that money to one or two paid developers. Look at it this way: Theo works on many many parts of the system. So does Miod. And so does Bob. As do many other developers who commit changes to LibreSSL. They're in it for OpenBSD. Can you tell them to forget OpenBSD and do LibreSSL for you?

EDIT: Or how about this? Sorry guys, this hackathon we're allowed to touch libssl only. Why? Because some people "donated" for us to work on LibreSSL and LibreSSL only. I don't think it can go like that. It becames work for money. Work on specific things people pay you to work on. Work for people who are voluntarily working on OpenBSD. I doubt many OpenBSD developers would attend such a hackathon.

It's simple: I have no current use for OpenBSD but I would use LibreSSL and I know a ton of other people in exactly the same boat. So I'd like my contributions to go where they make the most effect for me.

I kind of understand what you want but right now you have to acknowledge the reality that LibreSSL is a part of OpenBSD, its core developers are core OpenBSD developers, its source resides in the OpenBSD source tree, you get it from the servers that serve you OpenBSD. One is a part of the other. You can't really point at a fraction of the electricity bill and say that is for libssl. Likewise you can't say that a developer's laptop must only be used for working on libssl. And you can't say $5 (or whatever you donated) worth of an OpenBSD developer's time must go towards libssl and not something else. You may find that with no OpenBSD, there would be no security-minded OpenBSD developers to work on /usr/src/lib/libssl.

If you want to deny the project its money and only contribute to a part of it, the only way I can see that happening right now is that you hire a developer to work on the part you want.

Also, don't forget that developing software on OpenBSD is likely to make that software better (there are features that make OpenBSD a good development platform; and the fact that code is tested on many different hardware platforms helps). So while you might not be using OpenBSD, chances are the system is affecting you positively nevertheless. I'd also encourage you to look at how many other projects use code from OpenBSD. Do you use Android per chance?

The point is that as far as the OpenBSD project is concerned, LibreSSL isn't a thing on its own. It's just another component of OpenBSD. It's not even supposed to be portable across operating systems - making it so will likely be a separate project, essentially a fork, as it is with OpenSSH.

Can you imagine someone saying "I want to give you this gift but only if you focus on thing X (which I care about) and not on things Y and Z (which you care about)"?

Yes. One the one side you have a group called 'employers'. On the other side you have a group called 'contractors'. Contractors are free to work on whatever they feel like, but if they also want money, they should probably do some work for employers from time to time.

It's hardly rude to say "I value this, here is some money to help this along". If the devs see that plenty of people are giving money to 'this', then if they don't work on it, that channel will dry up. Donations aren't a gift like a christmas present, which you get to use on whatever you want. Donations are an enabling device usually intended for a particular cause. They don't mean you get to dictate the actions of the staff, but at the same time, the staff shouldn't be taking donations for work they don't care to do.

Common request, but no. First and foremost, the accounting overhead is annoying. If I spend two days at a hackathon working on smp, do I have to charge the hotel to a different account? Can I pretend the libressl work I did for free this week is exchangeable for paid work during a hackathon? It very quickly becomes a mess.

I think you get a pretty decent return on investment even if your dollars support openbsd features you don't use. All of us working on libressl are working in it because we work on openbsd, and we work on openbsd because others have made it a viable platform for us. Basically you may not care about openbsd desktops, but I do, and I'm only working on libressl because of that. Paying me market rates for this work would get a lot less done.

Particular example: libressl exists in part because of previous work done on exploit mitigation. Without that, there'd be no libressl.

Or, to put it another way, if you were to donate to me, I'd probably turn around and forward that money to openbsd foundation anyway.

All that said, you can mention that your donation is for libressl. That doesn't guarantee anything, but I'm sure there are unofficial tallies.

> Particular example: libressl exists in part because of previous work done on exploit mitigation. Without that, there'd be no libressl.

even though the "exploit mitigation" didn't work with Heartbleed, which was the reason libressl started.

Yes, that's what I just said. If OpenBSD hadn't included exploit mitigation, it wouldn't have not worked, and we wouldn't be here today.

I had to read that about five times to understand it :) Reading "had not" and "would not" on the fifth attempt did the trick.

Neither of these work if SSL_MODE_RELEASE_BUFFERS is enabled, and are the only two CVEs in secadv_20140605.txt that have a dependence on SSL_MODE_RELEASE_BUFFERS.

libreSSL isn't any better on this front than OpenSSL without SSL_MODE_RELEASE_BUFFERS.

Is LibreSSL also vulnerable to this?

Yes, there have been no audits of the protocol code yet. I have a feeling it will be patched shortly.

See Ted's comment here: https://news.ycombinator.com/item?id=7851949

I feel like there is a (potentially bad) typo in the second paragraph of this advisory.

Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution.

It seems to me that users on versions earlier then 1.0.1 would be advised not to upgrade since they stated in the sentence before that 1.0.1 is vulnerable.

------

edit: Oops, I feel kind of dumb. Literally the next line is describing the recommended upgrade for 0.9.8 users:

OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za.

They say, versions earlier than 1.0.1 might be vulnerable, we're not sure, so upgrade to the latest (presumably a newer version than 1.0.2-beta1).

"Upgrade" doesn't necessarily mean "upgrade to 1.0.1". Older versions are still getting updates. Unfortunately, this might not be clear to some readers because OpenSSL uses a weird versioning scheme. The three numbers stay the same, but the alphabetical part at the end gets incremented each time there's an update.

> OpenSSL 0.9.8 SSL/TLS users should upgrade to 0.9.8za.

> OpenSSL 1.0.0 SSL/TLS users should upgrade to 1.0.0m.

> OpenSSL 1.0.1 SSL/TLS users should upgrade to 1.0.1h.

Does this vulnerability compromise the private key? Should people generate new key pairs?

http://ccsinjection.lepidum.co.jp/

> No. Attackers cannot steal your private keys through this bug itself.

Does this one have a logo? I'm not going to take it seriously unless it has a logo.

It does: http://ccsinjection.lepidum.co.jp/

That's me told.

The change can be seen here:

https://github.com/openssl/openssl/commit/bc8923b1ec9c467755...

I noticed (in that commit anyway) there were no tests changed. Is it pretty standard not to test things like this? If I find a major bug in code I write, I usually write a test first and TTD until it's fixed.

Red Hat advisory for RHEL6 seems to be already available: https://rhn.redhat.com/errata/RHSA-2014-0625.html

Edit:

They also released a blog entry about the CCS injection issue: https://access.redhat.com/site/blogs/766093/posts/908133

It seems that both Heartbleed and this MITM vulnerability were introduced by Robin Seggelmann [1], which will surely drive a lot of speculations...

[1] http://h30499.www3.hp.com/t5/HP-Security-Research-Blog/ZDI-1...

Looking at all the attention openSSL is getting these days, I'd use another solution in my production servers (if security was an important concern).

https://status.heroku.com/incidents/636

Is it recommended to cycle ssl certs?

From http://ccsinjection.lepidum.co.jp/

Q. Do I have to re-create my private keys or certificates?

A. No. Attackers cannot steal your private keys through this bug itself. However if you have transferred your private keys via paths protected by SSL/TLS, the keys could be sniffed. If this is the case, consider regenerating the keys or certificates.

Anyone know if this has any impact on AWS Load Balancer?

It did, and it's being patched. http://aws.amazon.com/security/security-bulletins/openssl-se...

Reply on news.ycombinator.com