9 ms·

OpenSSL Security Advisory

149 points by jgrahamc 11y ago

theCricketer 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      Didn't say that. Just take a look at a "security comparison" between LibreSSL and OpenSSL: https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerabilities 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..
      - bch 11y ago
        > 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 11y ago
        > 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?
      - deleted 11y ago
        [deleted]
      - peterwwillis 11y ago
        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.
  - deleted 11y ago
    [deleted]
- 102030485868 11y ago
  The one the OpenSSL follows is documented here[0]. There's also the CVSS[1] which covers a broader scope. [0]: https://www.openssl.org/policies/secpolicy.html https://www.openssl.org/policies/secpolicy.html [1]: https://en.wikipedia.org/wiki/CVSS https://en.wikipedia.org/wiki/CVSS
cperciva 11y ago
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.
- danielhlockard 11y ago
  It at least sounds, theoretically, hard to execute?
  - jerf 11y ago
    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. It's moving stuff, for certain audiences.
    - badloginagain 11y ago
      I thought Cryptography was interesting, but I didn't know it was that interesting...
  - cperciva 11y ago
    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.
peterwwillis 11y ago
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 11y ago
  ouch ouch OUCH FreeBSD has to support 0.98 through the end of 2016
  - danielhlockard 11y ago
    A lot of packages can be compiled with a more modern version, though, even if it means more work.
    - peterwwillis 11y ago
      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 11y ago
        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 11y ago
        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.
pippy 11y ago
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 11y ago
  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 11y ago
    > 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 11y ago
      That's just not true. In fact, Heartbleed was the product of large-scale auditing that Google had been running on OpenSSL.
tux 11y ago
Title should be > OpenSSL Security Advisory [3 Dec 2015]
hannob 11y ago
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-miscalculations-in-OpenSSLs-BN_mod_exp-CVE-2015-3193.html https://blog.fuzzing-project.org/31-Fuzzing-Math-miscalculat... HN thread: https://news.ycombinator.com/item?id=10673407 https://news.ycombinator.com/item?id=10673407
ludbb 11y ago
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/d73cc256c8e256c32ed959456101b73ba9842f72/crypto/bn/asm/x86_64-mont5.pl 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/crypto/bn/asm/x86_64-mont5.pl 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/cf6d55961cfaa00eb1852ac67cc4896b22eb8079#diff-43d1ca7cd121250ad9cdaee09e53332a https://github.com/openssl/openssl/commit/cf6d55961cfaa00eb1..., which introduced the bug reported. BoringSSL patched it here: https://boringssl.googlesource.com/boringssl/+/e701f16bd69b6f251ed537e40364c281e85a63b2 https://boringssl.googlesource.com/boringssl/+/e701f16bd69b6... So, why LibreSSL went with a 2+ year old version of that file?
- PhantomGremlin 11y ago
  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 11y ago
    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 11y ago
      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.
arca_vorago 11y ago
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.

149 points by jgrahamc 11y ago

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 11y ago
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 11y ago
  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 11y ago
    Didn't say that. Just take a look at a "security comparison" between LibreSSL and OpenSSL: https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerabilities 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..
    - bch 11y ago
      > 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 11y ago
        > 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?
    - deleted 11y ago
      [deleted]
    - peterwwillis 11y ago
      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.
- deleted 11y ago
  [deleted]
102030485868 11y ago
The one the OpenSSL follows is documented here[0]. There's also the CVSS[1] which covers a broader scope. [0]: https://www.openssl.org/policies/secpolicy.html https://www.openssl.org/policies/secpolicy.html [1]: https://en.wikipedia.org/wiki/CVSS https://en.wikipedia.org/wiki/CVSS

cperciva 11y ago

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.

danielhlockard 11y ago
It at least sounds, theoretically, hard to execute?
- jerf 11y ago
  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. It's moving stuff, for certain audiences.
  - badloginagain 11y ago
    I thought Cryptography was interesting, but I didn't know it was that interesting...
- cperciva 11y ago
  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.

peterwwillis 11y ago

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 11y ago
ouch ouch OUCH FreeBSD has to support 0.98 through the end of 2016
- danielhlockard 11y ago
  A lot of packages can be compiled with a more modern version, though, even if it means more work.
  - peterwwillis 11y ago
    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 11y ago
      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 11y ago
        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.

pippy 11y ago

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 11y ago
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 11y ago
  > 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 11y ago
    That's just not true. In fact, Heartbleed was the product of large-scale auditing that Google had been running on OpenSSL.

tux 11y ago

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

hannob 11y ago

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-miscalculations-in-OpenSSLs-BN_mod_exp-CVE-2015-3193.html https://blog.fuzzing-project.org/31-Fuzzing-Math-miscalculat... HN thread: https://news.ycombinator.com/item?id=10673407 https://news.ycombinator.com/item?id=10673407

ludbb 11y ago

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/d73cc256c8e256c32ed959456101b73ba9842f72/crypto/bn/asm/x86_64-mont5.pl 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/crypto/bn/asm/x86_64-mont5.pl 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/cf6d55961cfaa00eb1852ac67cc4896b22eb8079#diff-43d1ca7cd121250ad9cdaee09e53332a https://github.com/openssl/openssl/commit/cf6d55961cfaa00eb1..., which introduced the bug reported. BoringSSL patched it here: https://boringssl.googlesource.com/boringssl/+/e701f16bd69b6f251ed537e40364c281e85a63b2 https://boringssl.googlesource.com/boringssl/+/e701f16bd69b6... So, why LibreSSL went with a 2+ year old version of that file?

PhantomGremlin 11y ago
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 11y ago
  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 11y ago
    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.

arca_vorago 11y ago

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.