
OpenSSL Security Advisory - jgrahamc
https://www.openssl.org/news/secadv/20151203.txt
======
cperciva
_BN_mod_exp may produce incorrect results on x86_64 (CVE-2015-3193)_

This one is absolutely terrifying. There are common ways that TLS stacks
break: Generally speaking, bugs in parsing certificates, bugs in the protocol
handling, and side channel attacks on the cryptography. These are risks which
we aim to work around -- just like infections are a known complication of
surgery, and antibiotic prophylaxis is recommended in some cases.

A bug which _results in multiplication producing the wrong answers_ is in a
completely different category. This is a "never event", akin to a surgical
scalpel being left inside a patient after surgery or the wrong leg being
amputated.

~~~
tptacek
Ralf-Phillip Weinmann had a good Black Hat presentation about this bug class.
It might not be online yet. He's part of one of a couple of efforts to come up
with fuzzing and validation tools to find things like carry propagation bugs
in bignum libraries.

The good news about this particular bug is that carry propagation bugs are
well-studied (they seem to be the textbook case of a bignum math bug), and if
OpenSSL says they've scoped down the places this bug impacts, they're probably
right.

I don't know if it mitigates your existential dread, but carry propagation
bugs in multiplication routines are not in fact all that rare.

~~~
cperciva
_carry propagation bugs are well-studied_

True. But they tend to be well-studied by computer security people, not by
mathematicians; and most computer security people won't have the necessary
number theory / group theory background.

This is precisely the class of bugs for which proper assessment requires
mathematicians who study computer security... aka. NSA employees.

~~~
Ar-Curunir
You'll be surprised by the background of many computer security people. It's a
varied field consisting of people with all kinds of backgrounds.

~~~
cperciva
My background is mathematics too. But I'm not a mathematician, and I wouldn't
trust myself to know enough mathematics to figure out how something like this
could be exploited.

------
ludbb
Interestingly, looks like LibreSSL avoided the BN_mod_exp bug.

OpenSSL history for crypto/bn/asm/x86_64-mont5.pl can be seen at:
[https://github.com/openssl/openssl/commits/d73cc256c8e256c32...](https://github.com/openssl/openssl/commits/d73cc256c8e256c32ed959456101b73ba9842f72/crypto/bn/asm/x86_64-mont5.pl)

LibreSSL is using an old version of that same file found at
[http://cvsweb.openbsd.org/cgi-
bin/cvsweb/src/lib/libssl/src/...](http://cvsweb.openbsd.org/cgi-
bin/cvsweb/src/lib/libssl/src/crypto/bn/asm/x86_64-mont5.pl). LibreSSL is
using a version (possibly with patches on top of it) that is at least before
[https://github.com/openssl/openssl/commit/cf6d55961cfaa00eb1...](https://github.com/openssl/openssl/commit/cf6d55961cfaa00eb1852ac67cc4896b22eb8079#diff-43d1ca7cd121250ad9cdaee09e53332a),
which introduced the bug reported.

BoringSSL patched it here:
[https://boringssl.googlesource.com/boringssl/+/e701f16bd69b6...](https://boringssl.googlesource.com/boringssl/+/e701f16bd69b6f251ed537e40364c281e85a63b2)

So, why LibreSSL went with a 2+ year old version of that file?

~~~
PhantomGremlin
_So, why LibreSSL went with a 2+ year old version of that file?_

The LibreSSL philosophy is to (at least initially) clean up the parts of
OpenSSL that are "cruft". E.g. dropping support for long-dead computer
architectures and protocols, removing homebrew malloc(). Stuff like that.

The LibreSSL guys have tried to stay away from the highly tricky crypto stuff.
Messing with that could have serious security implications. They can address
math and crypto later. For now there's still a lot of low hanging fruit they
can pick.

~~~
ludbb
I'm aware of that but it seems specially interesting that they decided to go
with a specific old version of some files. I don't think this kind of decision
was ever made public, was it?

The general clean up idea is mentioned all over, but selecting old versions of
specific files is not.

~~~
PhantomGremlin
_I don 't think this kind of decision was ever made public, was it?_

Not that I'm aware of. I follow the misc, tech, and libressl mailing lists and
there seems to be a lot of OpenBSD related stuff _missing_ from there. I think
the cabal uses other, more private, more informal, means of communication for
a lot of their discussions and decisions.

 _selecting old versions of specific files_

But did they really select an old version? Rather, perhaps they just declined
to pull the changes that the OpenSSL people made.

------
pippy
After the heartbleed bug I checked out the openssl code to see what the
quality was like. I was horrified from what I saw; single character variable
names outside of loops, preprocessor macro soup, no comments for functions.
I've told interns off for less.

Given the reliance on openssl I really hope companies that are using it are
doing robust automated checking on the codebase.

~~~
tptacek
It's one of the most heavily audited codebases on the planet. Nobody likes the
code quality, and Google has been restructuring it and rewriting it with their
BoringSSL project.

At this point: when new bug classes are discovered, like carry propagation in
optimized multiplication routines, or even simpler stuff like memory
corruption due to bignum copies, yes, there's some cause for alarm, because
you might not be able to count on OpenSSL having been audited for them.

But the basic stuff, at least in the core functionality (ie: not oddball TLS
extensions) has received a very good shake.

~~~
jimrandomh
> It's one of the most heavily audited codebases on the planet.

This is misleading. OpenSSL is probably one of the most heavily audited in
terms of number of auditors currently working on it, but this only started
with Heartbleed and there appears to be a large, unfinished backlog of things
to get through.

Looking at
[https://www.openssl.org/news/vulnerabilities.html#y2015](https://www.openssl.org/news/vulnerabilities.html#y2015)
, since Heartbleed 20 months have passed, and new security vulnerabilities
have been announced on 14 separate dates (and most of those dates are multiple
vulnerabilities being announced at the same time). This announcement breaks
the streak of most consecutive months without a new vulnerability, of which
there were almost five.

~~~
tptacek
That's just not true. In fact, Heartbleed was the product of large-scale
auditing that Google had been running on OpenSSL.

~~~
justinclift
Do you believe Google is or isn't a US company which would keep the most
interesting stuff to itself/NSA/US-TLA's?

Having Google audit the OpenSSL code is not really a problem... but believing
them to do things for the benefit of anyone else isn't really feasible.
They've shown themselves to be both good and bad actors on multiple occasions,
so trying to pick which one this is... guesswork. :(

~~~
simoncion
> Do you believe Google is or isn't a US company which would keep the most
> interesting stuff to itself/NSA/US-TLA's?

They are a US-based company.

They _absolutely_ would fix and/or publicly announce any vuln in a library
that they rely on, rather than keep quiet about it or -far worse- sell the
vuln information.

Do you have a credible example of an instance where they've acted to the
contrary?

~~~
ccrush
Hmm, no one has found out that they didn't tell us things. Clearly, that's
proof that they tell us everything. Good thing we got our answer. Time to stop
asking questions. Google tells us every time they find a serious vulnerability
in OpenSSL, so no need to worry that they might not.

~~~
simoncion
> Time to stop asking questions.

 _Absolutely_ not. Vigilance often keeps allies who might turn on you from
turning on you, and -when it fails to do that- it alerts you to their
treachery. This is why I _asked_ for evidence of Google's treachery, rather
than dismissing the possibility.

In _any_ significant conflict it is _very_ wise to have an idea of who your
stalwart allies are, and who you are able to currently rely on.

Any ally can turn on you at any time. That's human nature. However, the man
who allows himself _no_ allies is far weaker and far more susceptible to
attack than the man who has some.

Like any ally, Google may one day turn on us. For the past several decades,
examination of the reports from people working in a _variety_ of positions
inside the organization leads us to understand that -despite the fact that
Google is a huge advertising company- it realizes that insecure computers and
computer systems hurt them at _least_ as much as they hurt everyone else.
Those reports also lead us to understand that Google works _really_ hard to
ensure that the software that it relies on and the software that it produces
is as secure as it can be reasonably made, given the resources Google has
available.

If this confuses you, think of it this way: Google makes money by keeping the
data that it collects on you (and the analysis of that data) secure and out of
the hands of _everyone_ outside of Google. Because they use commodity hardware
and software in the regular course of their business, they find themselves
testing and fixing issues in software and -sometimes- hardware that we all
use.

Because there is no competitive advantage for them to withhold those fixes
(indeed, doing so makes _everyone_ safer and keeps them using their computers,
which keeps delicious data flowing into Google's robots), Google publishes
these fixes on a regular basis.

I look forward to your cogent reply.

------
hannob
I've written up some details on the BN_mod_exp issue that I found with
american fuzzy lop: [https://blog.fuzzing-project.org/31-Fuzzing-Math-
miscalculat...](https://blog.fuzzing-project.org/31-Fuzzing-Math-
miscalculations-in-OpenSSLs-BN_mod_exp-CVE-2015-3193.html) HN thread:
[https://news.ycombinator.com/item?id=10673407](https://news.ycombinator.com/item?id=10673407)

------
peterwwillis

      NOTE: WE ANTICIPATE THAT 1.0.0t AND 0.9.8zh WILL BE THE LAST RELEASES FOR THE
      0.9.8 AND 1.0.0 VERSIONS AND THAT NO MORE SECURITY FIXES WILL BE PROVIDED (AS
      PER PREVIOUS ANNOUNCEMENTS). USERS ARE ADVISED TO UPGRADE TO LATER VERSIONS.
    

Start filling out your upgrade/migration change request forms now, admins.

~~~
feld
ouch ouch OUCH

FreeBSD has to support 0.98 through the end of 2016

~~~
danielhlockard
A lot of packages can be compiled with a more modern version, though, even if
it means more work.

~~~
peterwwillis
The problem isn't whether modern versions work; the problem is re-testing &
re-certifying your application on the platform, because you don't know what
features might have changed or broken with the upgrade. It can sometimes be
cheaper to pay an engineer to backport or make custom patches if vulns are
found in the future.

~~~
yeukhon
Yeah. regression testing, even though it is likely that most people won't see
breakage or regression from upgrading to the latest, but some testing should
still be done.

~~~
peterwwillis
Some companies also have entire application suites based on a patchset based
on a particular version, so before you can even do your whole regression
suite, you first have to re-write your entire patchset to work with the
upgrade.

In short: Ouch.

------
tux
Title should be > OpenSSL Security Advisory [3 Dec 2015]

------
theCricketer
Just curious (I'm a nobody in the security field to doubt anything): What is
the process to vet the correctness of the description of the severity? I
imagine these notices are pretty important so when they describe subjective
things like how difficult and likely it is to take advantage of this loophole,
is there a standard for how to assess such things?

~~~
peterle
The "severity" is often not accurate. OpenSSL recently marked an issue as
lowly severe, but in fact its severity was high.

Don't trust them. OpenSSL is bad, use LibreSSL instead. OpenSSL == NSA. For
sure they know weaknesses and actively exploit them if required.

EDIT: I'm talking about this advisory:
[https://www.openssl.org/news/secadv/20150108.txt](https://www.openssl.org/news/secadv/20150108.txt)

~~~
danielhlockard
I'm not saying you're wrong, I'm just saying LibreSSL isn't bug free either:
[https://en.wikipedia.org/wiki/LibreSSL#15_October_2015](https://en.wikipedia.org/wiki/LibreSSL#15_October_2015)
buffer overflows and memory leaks aren't great.

~~~
peterle
Didn't say that.

Just take a look at a "security comparison" between LibreSSL and OpenSSL:
[https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerab...](https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerabilities)

Severity LibreSSL OpenSSL

High 0 5

Medium 15 28

Low 7 10

Total 22 43

LibreSSL has had no "high" vulnerabilities, whereas OpenSSL had 5. Decide for
yourself which way to go.

EDIT: Sorry, can't format that table nicely here..

~~~
bch
> The "severity" is often not accurate. OpenSSL recently marked an issue as
> lowly severe, but in fact its severity was high.

...

> LibreSSL has had no "high" vulnerabilities, whereas OpenSSL had 5. Decide
> for yourself which way to go.

I'm not defending or apologizing for OpenSSL (or any project), but your
rationale isn't consistent, seemingly only trying to evoke an emotional
response.

Since heartbleed, lots of new SSL implementations have sprung up (Libre,
Boring, etc), and hard lights have shone on OpenSSL as well. The scrutiny and
competition will come to be win for all consumers of SSL. It's not clear to me
(as a consumer) that any project has a huge leg-up over another (though
Libre's wholesale dump of a tremendous amount of legacy code sounds like a
step in the right direction).

Do we even know this won't show up in other (Boring, Libre) implementations as
well ?

Edit: formatting

~~~
neerdowell
_> I'm not defending or apologizing for OpenSSL (or any project), but your
rationale isn't consistent, seemingly only trying to evoke an emotional
response._

The GP is pointing out that LibreSSL has avoided the 5 vulnerabilities that
OpenSSL marked sev:high since the fork. There isn't any inconsistency about
that, it's a pure apples-with-apples comparison.

 _> It's not clear to me (as a consumer) that any project has a huge leg-up
over another_

LibreSSL has avoided almost half of the OpenSSL vulnerabilities found since
the work. What more do you want?

------
arca_vorago
I'm no longer surprised at openssl issues having looked at the code.
Personally and professionally, I have slowly been transitioning to mbed (was
PolarSSL before ARM bought it). For those who haven't seen it, it's worth
checking out.

