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?
> 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 ?
> 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?
Format tip: prefix a block of lines with two spaces (on each line) and a newline before and after the block to turn it into a fixed-width font, then format ASCII-style.
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.
I believe cperciva's more trying to convey deep existential angst moreso than immediate threat.
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.
Maybe. The problem with getting such fundamental things wrong is that it's almost impossible to figure out every possible way to exploit it.
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.
Sure, and "multiplication produces incorrect results" can be avoided by careful code review. It's still a "never event", and in a completely different category from postoperative infections.
The "goto fail;" was the one that really terrified me, as it is something that can be caught by straightforward (even black-box) testing (which was not being done for some reason by the largest corporation in the world).
Not without looking at the code first. But the first thing which comes to mind is accidentally generating RSA primes which aren't prime because the broken multiplication makes a SPSP test accidentally pass.
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.
Not private key in public-key schemes (RSA, DH), because these are generally random integer and BN_mod_exp is not used in private key generation -- but it's used in public key generation so the result could be an invalid key pair.
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.
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.
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.
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.
I have only basic knowledge of this but it feels like it should be possible to mathematically prove the correctness of bignum implementation, even if it's in C, no? And it would be very valuable work too.
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.
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.
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.
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.
Aye, but a lot of others won't. Also, there are a number of other vendors, like RedHat and CentOS, that have assumedly committed to continue supporting OpenSSL 0.9.8xx for up to nine more years per their support policy.
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.
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.
> 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 , 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.
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. :(
> 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?
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.
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.
Okay, I may've been wrong about exactly when the auditing started, but do we agree that the number of security vulnerability announcements in the past year is somewhat predictive of the number of announcements coming in the next? For me the main worry is attacks from people who aren't doing their own research but just exploiting the window between the public announcement and when I get the patches installed, and I really wish there were fewer such windows.
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.
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.
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.
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.
65 comments
[ 6.5 ms ] story [ 212 ms ] threadDon'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?
[0]: https://www.openssl.org/policies/secpolicy.html
[1]: https://en.wikipedia.org/wiki/CVSS
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.
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.
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.
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.
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.
https://www.youtube.com/watch?v=PqW8-MUu09c
https://comsecuris.com/research/slides-bignum-bhus2015.pdf
FreeBSD has to support 0.98 through the end of 2016
In short: Ouch.
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.
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.