
OpenSSL Security Advisory - davidroetzel
https://www.openssl.org/news/secadv_20140605.txt
======
ctz
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.

~~~
JacobAldridge
_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.

~~~
reaperhulk
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](https://www.imperialviolet.org/2014/06/05/earlyccs.html)

~~~
mnw21cam
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.

~~~
ZoFreX
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.

~~~
PhantomGremlin
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.

------
jgrahamc
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.

~~~
rdl
This should be interesting for OpenVPN.

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

[http://www.pcworld.com/article/2143440/server-makers-
rushing...](http://www.pcworld.com/article/2143440/server-makers-rushing-out-
heartbleed-patches.html)
[http://www.networkworld.com/article/2176022/router/heartblee...](http://www.networkworld.com/article/2176022/router/heartbleed-
bug-hits-at-heart-of-many-cisco--juniper-products.html)

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.

~~~
syzzer
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--...](https://community.openvpn.net/openvpn/wiki/Hardening#Useof
--tls-auth)

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.

~~~
peterwwillis
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.

~~~
agwa
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.

~~~
JoachimSchipper
tls-auth does prevent replays: note the "packet-id for replay protection" at
[http://openvpn.net/index.php/open-
source/documentation/secur...](http://openvpn.net/index.php/open-
source/documentation/security-overview.html).

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.)

------
reaperhulk
Logos are now prerequisite, so of course CVE-2014-0224 has you covered.
[http://ccsinjection.lepidum.co.jp](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...](https://github.com/openssl/openssl/commits/OpenSSL_1_0_1-stable)

OpenSSL 1.0.0:
[https://github.com/openssl/openssl/commits/OpenSSL_1_0_0-sta...](https://github.com/openssl/openssl/commits/OpenSSL_1_0_0-stable)

OpenSSL 0.9.8:
[https://github.com/openssl/openssl/commits/OpenSSL_0_9_8-sta...](https://github.com/openssl/openssl/commits/OpenSSL_0_9_8-stable)

~~~
kerneis
"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).

~~~
johnkeeping
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...](http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-
en/index.html)

------
gamed
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.

~~~
jacquesm
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).

~~~
Florin_Andrei
> _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.

~~~
TillE
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.

~~~
Florin_Andrei
Teardrop was fantastic.

------
0x0
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://lists.debian.org/debian-security-
announce/2014/msg00130.html)
[https://news.ycombinator.com/item?id=7851535](https://news.ycombinator.com/item?id=7851535)

------
reaperhulk
Debian advisory: [https://lists.debian.org/debian-security-
announce/2014/msg00...](https://lists.debian.org/debian-security-
announce/2014/msg00129.html)

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

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

Ubuntu advisory: [https://lists.ubuntu.com/archives/ubuntu-security-
announce/2...](https://lists.ubuntu.com/archives/ubuntu-security-
announce/2014-June/002532.html)

~~~
dorfsmay
Anybody know what the difference is between Ubuntu package

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

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

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

[2]:
[http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/...](http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/openssl_1.0.1e-3ubuntu1.4/changelog)

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

~~~
tedunangst
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.

~~~
jacquesm
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?

~~~
clarry
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.

~~~
jacquesm
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.

~~~
clarry
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?

------
ishatmypants
Is LibreSSL also vulnerable to this?

~~~
X-Istence
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](https://news.ycombinator.com/item?id=7851949)

------
thefreeman
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._

~~~
kijin
"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.

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

~~~
danielweber
[http://ccsinjection.lepidum.co.jp/](http://ccsinjection.lepidum.co.jp/)

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

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

~~~
korstiaan
It does:
[http://ccsinjection.lepidum.co.jp/](http://ccsinjection.lepidum.co.jp/)

~~~
billpg
That's me told.

------
lucaspiller
The change can be seen here:

[https://github.com/openssl/openssl/commit/bc8923b1ec9c467755...](https://github.com/openssl/openssl/commit/bc8923b1ec9c467755cd86f7848c50ee8812e441)

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.

------
m4r71n
Red Hat advisory for RHEL6 seems to be already available:
[https://rhn.redhat.com/errata/RHSA-2014-0625.html](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](https://access.redhat.com/site/blogs/766093/posts/908133)

------
mnicky
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...](http://h30499.www3.hp.com/t5/HP-Security-Research-
Blog/ZDI-14-173-CVE-2014-0195-OpenSSL-DTLS-Fragment-Out-of-
Bounds/ba-p/6501002#.U5Cjpnmx3UY)

------
anon12
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).

------
fomb
[https://status.heroku.com/incidents/636](https://status.heroku.com/incidents/636)

------
zekenie
Is it recommended to cycle ssl certs?

~~~
danielweber
From [http://ccsinjection.lepidum.co.jp/](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.

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

~~~
TheCustos
It did, and it's being patched. [http://aws.amazon.com/security/security-
bulletins/openssl-se...](http://aws.amazon.com/security/security-
bulletins/openssl-security-advisory/)

