
OpenSSL Security Advisory - jgrahamc
https://www.openssl.org/news/secadv/20160922.txt
======
VeejayRampay
My first reaction: This _never_ ends, does it? Second reaction: Security is
notoriously hard, nice that people are looking at the code and being thorough,
it's for the collective best.

~~~
hannob
What never ends? Low severity memory safety bugs in a large C codebase?
Probably not.

You may think this is a lot. It's not. This largely appears a lot because
OpenSSL treats a lot of very low impact issues as vulnerabilities. A lot of
other projecs would rather start arguing that this is not exploitable, should
never get a CVE etc. This is a good sign. OpenSSL is taking security seriously
by treating even low impact things as vulns. More severe stuff still happens,
but I'm pretty positive there is a decline in severe issues.

~~~
nine_k
Exactly. With C, it will effectively never end. Libraries like that would
probably benefit most from using a language with strict static analysis, like
Rust. Tools Of similar nature for C do exist, but probably they are harder to
apply, and likely not free.

~~~
fredmorcos
I hope I don't come across too harsh.

Is HN still really up for that argument? Yes, we know the downsides of C. But
the upside is that _we know the downsides of C_.

Constantly complaining about C isn't going to get anyone anywhere. It's been
shown over and over again that secure C coding is possible and doable and
feasible and exists in the real world. Some of the most secure software is
written in C, and that's not attributed to enough fingers banging at a
keyboard over a C program, but because C forces the programmer that _wants_ to
write a secure program think about all the issues, the universe and
everything.

So please, pave the road and show us the safer OpenSSL-rust you have. Until
then good luck and thank you for your feedback.

~~~
ctz
I've spent a career of 12 years writing, reviewing and breaking C in high-
security products such as HSMs. I'm still to see real world, secure C. Maybe
you could point me towards the numerous real world examples of people getting
this right. I'd prefer scaled-up outcomes here, not just saying 'djb wrote
qmail'.

(Incidentally, I don't have a quarrel with C specifically. All memory-unsafe
languages expand the range of terrible vulnerabilities available to the
engineer. This is not defensible these days, in my view.)

> So please, pave the road and show us the safer OpenSSL-rust you have.

My contribution here is
[https://github.com/ctz/rustls](https://github.com/ctz/rustls)

~~~
andrewchambers
I think OpenBSD beg to differ.

Not to mention I would argue memory exhaustion bugs like this happen in memory
safe garbage collected languages frequently too.

~~~
lambdasquirrel
There are edge cases for everything. A language is what it makes easy.

------
dijit
Luckily I moved everything to openbsd's libressl which is /mostly/ compatible.

I wonder if this bug affects them, typically the HIGH's haven't[0]

It really feels like every other week there is a bug in OpenSSL and after
following along with the libressl blog I understand why- the code is an
absolute mess[1]

[0]
[http://undeadly.org/cgi?action=article&sid=20150319145126](http://undeadly.org/cgi?action=article&sid=20150319145126)

[1] [http://opensslrampage.org/page/49](http://opensslrampage.org/page/49)

~~~
throwaway7767
The interesting thing about LibreSSL is that it's got such a halo around it
that people just assume it's not vulnerable to any OpenSSL bugs.

Practically every OpenSSL bug posted here gets the standard "Luckily LibreSSL
isn't affected by this kind of thing" response. On a couple of occasions I've
taken the bait and linked to the LibreSSL source to show that the relevant
bits are in fact not changed at all, so they were both vulnerable.

Not saying LibreSSL isn't doing good stuff, I just wish people would actually
check if it's affected before using any opportunity to jump on the let's-hate-
on-openssl bandwagon.

(I haven't looked into these bugs in the LibreSSL code since I don't have time
for it right now, but I'm sure some message is forthcoming).

~~~
OrpheanBeholder
No one is claiming that LibreSSL has fixed all the OpenSSL bugs, the parent
certainly didn't. LibreSSL has historically been vulnerable to _less_ of the
bugs than OpenSSL and, for a long time, none of the sev:high bugs.

~~~
anon1385
>none of the sev:high bugs.

Well it looks like that has just changed:
[https://marc.info/?l=libressl&m=147454940615412&w=2](https://marc.info/?l=libressl&m=147454940615412&w=2)

------
cperciva
OK, _now_ we can go ahead with FreeBSD 11.0-RELEASE.

In my time as security officer, it was a rare and surprising occurrence when
we didn't need to hold an upcoming release due to a pending OpenSSL advisory.
It got to the point of the release engineer saying "I think we're ready to
start the release builds tomorrow, any news from OpenSSL" and me replying
"nothing yet, but I'm sure it will come" \-- their timing was absolutely
impeccable.

~~~
astrodust
LibreSSL isn't up to speed yet?
[http://www.libressl.org](http://www.libressl.org)

~~~
cperciva
It certainly wasn't when I was Security Officer -- it didn't exist yet.

I believe some people are working on bringing libressl into the FreeBSD base
system, but there are some challenges; for example, FreeBSD supports stable
branches for 5 years, while libressl follows OpenBSD's "break everything once
a year" model.

~~~
tedunangst
Could be biased, but I think we're more careful about bundling breaking
changes in security patches though.

~~~
cperciva
If you try at all, then you're trying harder than OpenSSL. But that doesn't
necessarily help if there has been so much code churn over the past 5 years
that we can't figure out how or if we should apply the security patch.

------
MichaelMoser123
if i understand correctly this one is relevant to certificate issuers that
publish certificate revocation lists via the OCSP protocol; could be used for
denial of service but not for hacking into the certificate issue, is that
correct?

Also most bugs in OpenSSL seem to be during renegotiation of protocol zzzz
defined by some obscure RFC that nobody really understands how to implement,
is that correct? Why can't they simplify these protocols, do we really need
these fancy renegotiation features?

Actually Daniel Bernstein says that over-complicating the protocols is a
clever way to make sure that software infrastructure remains insecure.

[https://cr.yp.to/talks/2014.10.18/slides-
djb-20141018-a4.pdf](https://cr.yp.to/talks/2014.10.18/slides-
djb-20141018-a4.pdf)

~~~
AlyssaRowan
Simplifying the protocol, making it easier to analyse (and prove) and
especially removing legacy things we know are troublesome is the main goal of
the draft TLS 1.3: now already live and rolled out across CloudFlare and
Chrome, and which removes such things as renegotiation, all non-AEAD
ciphersuites, MD5, SHA-1, static RSA, and many of the other classic TLS
bugbears which keep bearing interesting vulnerabilities.

Which isn't to say the optional (but usefully fast) 0-RTT mode might not
introduce a few more, for those lackadaisical devs who inevitably ignore all
dire warnings and abuse it for non-idempotent requests like POSTs (or GETs
that _do something_ \- bad idea!).

But even if it's not how I would have designed it afresh (the Noise Protocol
Framework from Trevor Perrin is how I would have designed a new connection
protocol now) it's still a big improvement over previous TLS/SSL iterations
and a drastic enough change it probably deserves to be called TLS 2.0.

------
justinmayer
As far as I can tell, patched OpenSSL packages for affected Debian/Ubuntu
releases are not yet available.

[https://security-tracker.debian.org/tracker/CVE-2016-6304](https://security-
tracker.debian.org/tracker/CVE-2016-6304)

[https://people.canonical.com/~ubuntu-
security/cve/2016/CVE-2...](https://people.canonical.com/~ubuntu-
security/cve/2016/CVE-2016-6304.html)

~~~
jaryd
You'll typically see these come through USN (Ubuntu Security Notices) as
they're available.

[http://www.ubuntu.com/usn/](http://www.ubuntu.com/usn/)

------
_jomo
The relevant commit (fix):
[https://github.com/openssl/openssl/commit/e408c09bbf7c3057bd...](https://github.com/openssl/openssl/commit/e408c09bbf7c3057bda4b8d20bec1b3a7771c15b)

Edit: This is only the commit for the HIGH severity CVE-2016-6304.

~~~
0x0
That's just one of many commits related to today's advisory.

[https://security-tracker.debian.org/tracker/source-
package/o...](https://security-tracker.debian.org/tracker/source-
package/openssl) has a good overview of each issue with links to commits etc
on each CVE entry.

~~~
tajen
I don't understand your link, it lists this issue under "Open Issues" – Does
that mean the fix for Debian isn't published yet?

~~~
0x0
That's correct. Knowing Debian, there's probably an update coming in the next
few hours.

------
robryk
Why is the severity of the first vulnerability high? It allows a denial of
service on the server's side by a client and nothing else. The second
vulnerability seems to be very similar in severity, except that it can be used
both against clients and servers, and yet it is of just moderate severity.
What am I missing?

~~~
adekok
Presumably because fewer applications use SSL_peek().

But yes, that issue is a serious problem, too.

------
beezle
Wonderful. Glad I recently added OCSP support to servers. Arg!

So does this affect TLSv1.2 only servers that do NOT support client
renegotiation of any type?

~~~
deweerdt
This is the only claim that i've found saying that throttling (or disabling,
for that matter) renegotiation would prevent the issue:
[https://twitter.com/Unreal_IRCd/status/778975019829489664](https://twitter.com/Unreal_IRCd/status/778975019829489664)

The advisory makes it sound like that would be the case, but it would have
been great if that was explicitly stated.

------
nodesocket
Does not appear that SSL Labs
([https://www.ssllabs.com/ssltest](https://www.ssllabs.com/ssltest)) tests for
this exploit (CVE-2016-6304) yet. Anybody have instruction on how to test your
server?

------
pdevr
>"Servers using OpenSSL versions prior to 1.0.1g are not vulnerable in a
default configuration [..]"

In case anyone is using older versions, like we do in our production
environment.

------
turingbook
>This issue was reported to OpenSSL by Shi Lei (Gear Team,Qihoo 360 Inc.)

A Chinese hacker

~~~
rurban
No. See
[https://en.wikipedia.org/wiki/Qihoo_360](https://en.wikipedia.org/wiki/Qihoo_360)

A very popular chinese anti-virus company which fashions the US freemium
model, with advertising on their homepage being the biggest revenue, and a
market cap of $11.42B. Not a hacker.

------
Yuioup
If it does not have a home page and a catchy name like "Heartbleed", then this
bug does not exist.

~~~
discreditable
There's one in the advisory for CVE-2016-2183 -
[https://sweet32.info](https://sweet32.info).

I'm trying to track these sites, mainly for my own amusement:
[https://github.com/KeenRivals/Bugsite-
Index](https://github.com/KeenRivals/Bugsite-Index)

~~~
slavik81
Thanks to you, my new favourite is
[http://backronym.fail](http://backronym.fail)

