OpenSSL Security Advisory
openssl.org
openssl.org
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.
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.
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.
In addition, I think it could produce a wrong symmetric key, as a result of a bad computation e.g. in the Diffie-Hellman protocol. So you could have insecure symmetric (e.g., AES) keys.
Granted, finding a concrete example would probably be very difficult, considering that replacing modexp by rand() is only going to pass N as a suspected prime with probability 1/N; but the question was can it, not will anyone ever find an example.
His post is shot in black and white, as he is smoking while sitting in an cafe on an otherwise abandoned European street, when the desultory wind blows in a creased newspaper with the headline "MODULAR MATH FOUND NOT TO WORK", and he turns to look at the camera with a slowly developing look of pure horror that the camera person spends a full 5 minutes in exploring every last nuance of. Just over two minutes in, a violinist wearing a tutu wanders in, plays some 12-tone music, delivers a poorly subtitled rumination on the ultimate futility of life and its connection to prime number elliptic curves, and then leaves, for no apparent reason.
It's moving stuff, for certain audiences.
I haven't looked at the code in question, but I'd be willing to bet that the NSA has figured out a way to exploit the broken multiplication which is completely unlike what the OpenSSL authors were considering.
OpenSSL history for crypto/bn/asm/x86_64-mont5.pl can be seen at: https://github.com/openssl/openssl/commits/d73cc256c8e256c32...
LibreSSL is using an old version of that same file found at http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/.... LibreSSL is using a version (possibly with patches on top of it) that is at least before https://github.com/openssl/openssl/commit/cf6d55961cfaa00eb1..., which introduced the bug reported.
BoringSSL patched it here: https://boringssl.googlesource.com/boringssl/+/e701f16bd69b6...
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.
The general clean up idea is mentioned all over, but selecting old versions of specific files is not.
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.
Given the reliance on openssl I really hope companies that are using it are doing robust automated checking on the codebase.
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.
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 , 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.
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. :(
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?
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.
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.
FreeBSD has to support 0.98 through the end of 2016
In short: Ouch.
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
Just take a look at a "security comparison" between LibreSSL and OpenSSL: https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerab...
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..
...
> 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
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?