25 ms·

OpenSSL high-severity bug – affects 1.1.1d, 1.1.1e, 1.1.1f

189 points by AngeloR 6y ago

9wzYQbTYsAIc 6y ago
> This issue was found by Bernd Edlinger and reported to OpenSSL on 7th April 2020. It was found using the new static analysis pass being implemented in GCC, -fanalyzer. 2 week turnaround time, not bad I guess, for something found by a static analyzer.
nayuki 6y ago
What popular software contain these vulnerable versions of the OpenSSL library?
- erichdongubler 6y ago
  This is a good question. Also important to remember is that for many Linux distributions dynamically linked OpenSSL artifacts are what end up getting used by the vast majority of binaries.
  - jolmg 6y ago
    Yeah, I was thinking by all of the binaries. I had forgotten that there's software that bundle it independently of the distro's library. Another comment mentioned docker images, and I've remembered that ruby also bundles it for its own use.
- AngeloR 6y ago
  I have no idea what a full list looks like.. but the nginx:1.17.10-alpine docker image contains the following: / # nginx -V nginx version: nginx/1.17.10 built by gcc 9.2.0 (Alpine 9.2.0) built with OpenSSL 1.1.1d 10 Sep 2019
  - ajp 6y ago
    Mine has a "running with..." part after that. built with OpenSSL 1.1.1d 10 Sep 2019 (running with OpenSSL 1.1.1g 21 Apr 2020)
    - sigotirandolas 6y ago
      If it doesn't print the "running with" line, it's running with the same version it was built with: https://hg.nginx.org/nginx/file/stable-1.18/src/core/nginx.c#l431 https://hg.nginx.org/nginx/file/stable-1.18/src/core/nginx.c...
- pmorici 6y ago
  Any embedded system that uses a recent version of buildroot and includes openssl. Starting with at least version 2019.02.9
- Shorel 6y ago
  MySQL
judge2020 6y ago
At least it's just DOS and not anything like heartbleed.
stuff4ben 6y ago
This would primarily affect web servers exposing SSH access to the public right? I suppose it also affects internally accessible servers as well but to a lesser degree in terms of priority.
- detaro 6y ago
  SSH != SSL. EDIT: Expect web servers running HTTPS in modern configurations to be affected, and other TLS based protocols. SSH is fine.
  - chupa-chups 6y ago
    Both SSH and SSL base on TLS. The leak in question has a problem > during or after a TLS 1.3 handshake Sure, openSSL is not SSH, but it is not unreasonable to assume this leak may affect web servers as well (e.g. by being based on the same underlying TLS implementation). "SSH != SSL" is a bit short to invalidate the assumption of the OP. I'd not be so sure this problem does not affect "web server X". https://en.wikipedia.org/wiki/Transport_Layer_Security https://en.wikipedia.org/wiki/Transport_Layer_Security OK, learnt something new today: https://crypto.stackexchange.com/questions/60255/why-doesnt-ssh-use-tls https://crypto.stackexchange.com/questions/60255/why-doesnt-... https://xkcd.com/1053/ https://xkcd.com/1053/ Thanks! :)
    - hannob 6y ago
      > Both SSH and SSL base on TLS No.
      - deleted 6y ago
        [deleted]
    - detaro 6y ago
      The parent is asking if primarily servers exposing "SSH" are affected. I should be less glib though, fair enough. will edit.
    - notaplumber 6y ago
pronoiac 6y ago
Checking out packages.ubuntu.com, it looks like the only version impacted is "focal;" the other versions are too old.
- lvs 6y ago
  Is there a reason why something as important as openssl is not being backported to keep up with the most recent versions?
  - richardwhiuk 6y ago
    Compatibility with other libraries and testing effort. You end up back porting everything. Ubuntu backports the fixes them instead (i.e. Ubuntu's 1.0.2 will be patch with CVE fixes going forward instead of backporting 1.1 wholesale).
    - kakwa_ 6y ago
      Also stability of APIs/ABIs: within a major Ubuntu/Debian version, there is an implicit contract in most cases that if you build something against a library/software provided by the distribution, it will not break after an upgrade of said library/software. To enforce that, a policy of version freeze+backport of bug/security fixes is almost always necessary as very few upstream projects will maintain separate branches and have a clear policy about API/ABI breakages. (OpenSSL is actually somewhat of an exception in that regard).
      - ymse 6y ago
        OpenSSL actually did a breaking API change as recent as 1.1.1e (reverted in 1.1.1f to be fair): https://bugs.python.org/issue40018 https://bugs.python.org/issue40018 And broke the ABI in 1.0.2g: https://bugzilla.redhat.com/show_bug.cgi?id=1313509 https://bugzilla.redhat.com/show_bug.cgi?id=1313509 I don't mean to bash on OpenSSL here and agree they generally do an exceptional job at keeping the public interface stable. Just offering some context. These things are difficult.
snvzz 6y ago
Sure, let's continue to reward incompetence by further funding openssl. In a sane world, everybody would have switched to libressl ages ago.
- mlindner 6y ago
  LibreSSL has all of the same problems as OpenSSL. It's just a fork from an earlier point in time before OpenSSL did it's big rewrite that came with OpenSSL 1.1.1.
- vladsanchez 6y ago
  I gather that LibreSSL has an (unintended) OpenSSL dependency? "LibreSSL is composed of four parts: - The openssl(1) utility, which provides tools for managing keys, certificates, etc. - libcrypto: a library of cryptography fundamentals - libssl: a TLS library, backwards-compatible with OpenSSL - libtls: a new TLS library, designed to make it easier to write foolproof application" :shrug:
  - notaplumber 6y ago
    No, LibreSSL is a fork of OpenSSL that predates this vulnerability, it even predates the OpenSSL 1.1.x API break (some compatibility has since been added), and has an entirely separate and new TLS 1.3 implementation. https://www.openbsd.org/papers/bsdcan2019-tls13.pdf https://www.openbsd.org/papers/bsdcan2019-tls13.pdf (video: https://www.youtube.com/watch?v=MCVIBwGOwNY https://www.youtube.com/watch?v=MCVIBwGOwNY) It maintains source compatibility with OpenSSL at an API and command-line level (e.g. openssl(1) utility). LibreSSL cannot copy code from later versions of OpenSSL as they relicensed it under the Apache 2.0 license.
- pnako 6y ago
  The few who switched to LibreSSL actually switched back to OpenSSL (Alpine, HardenedBSD). Void is considering switching back too: https://github.com/void-linux/void-packages/issues/20935 https://github.com/void-linux/void-packages/issues/20935
  - 6y ago
nayuki 6y ago
OpenSSL vulnerabilities: The gift that keeps on giving.
- takeda 6y ago
  I suppose so, but this bug only allows to crash the application. No doubt OpenSSL is buggy, but its problem is that a lot of applications depend on it as well. I'm hoping it will eventually reach status of bind or sendmail, they had also very bad track record, but vulnerabilities now are quite rare.
  - nayuki 6y ago
    The article says: "may crash due to a NULL pointer dereference". But in C, dereferencing a null pointer is undefined behavior. Crashing is only one possible outcome, and arguably the best outcome. The compiler and optimizer is entitled to elide certain checks or simplify code under the assumption that a pointer being dereferenced should not be null, and this could lead to dangerous things. Here's an artificial example: int x = 0; int *p; if (...some condition...) p = &x; else p = NULL; print(*p); The compiler is allowed to simplify the code to: int x = 0; int *p; p = &x; print(*p); It's because the 'else' branch must cause a null pointer dereference, so that case can be legally ignored.
    - takeda 6y ago
      I would imagine that if a compiler would be able to make this kind of optimization it would also be able to warn that this is an error. Also optimizers supposed to replace code with a simpler equivalent ones, in your example actually the if statement should block the optimization i.e. if there was no "if", the x would be used directly, and the pointer was ignored. Here's the bug: https://svnweb.freebsd.org/base/releng/12.1/crypto/openssl/ssl/t1_lib.c?r1=352546&r2=360150&pathrev=360150 https://svnweb.freebsd.org/base/releng/12.1/crypto/openssl/s... Value NULL is generally (void *)0 (could be different on different architectures, but it supposed to point to invalid value in memory, so when that memory address is accessed it will trigger segmentation fault.
vladsanchez 6y ago
OpenSSL is the culprit of a MacPort installation issue (vde2) for which there is no maintainer. It exposes operational vulnerability to unmaintained open source software.
- Avamander 6y ago
  Lets be fair, unmaintained proprietary software has the same vulnerability.
- saagarjha 6y ago
  This looks like it should be vde2's problem, not OpenSSL's: https://lists.macports.org/pipermail/macports-users/2019-October/047482.html https://lists.macports.org/pipermail/macports-users/2019-Oct...
- geofft 6y ago
  Just to make sure I understand - you're saying that because OpenSSL is under active maintenance and vde2 is not, OpenSSL is in the wrong? If you want to use unmaintained software, you know OpenSSL 1.0 still exists in this world, right?
agumonkey 6y ago
Now I know why arch pushed a new version this afternoon.
codewiz 6y ago
Is BoringSSL affected?
- ccktlmazeltov 6y ago
  or LibreSSL?
  - notaplumber 6y ago
    No. LibreSSL fork predates the issue, and has its own TLS 1.3 implementation. I'd expect the situation to be similar with Google's BoringSSL, but I don't how closely they track OpenSSL, if at all.
usr1106 6y ago
So how widely TLS 1.3 is a) used b) enabled in either client or server?

189 points by AngeloR 6y ago

> This issue was found by Bernd Edlinger and reported to OpenSSL on 7th April 2020. It was found using the new static analysis pass being implemented in GCC, -fanalyzer. 2 week turnaround time, not bad I guess, for something found by a static analyzer.

nayuki 6y ago

What popular software contain these vulnerable versions of the OpenSSL library?

erichdongubler 6y ago
This is a good question. Also important to remember is that for many Linux distributions dynamically linked OpenSSL artifacts are what end up getting used by the vast majority of binaries.
- jolmg 6y ago
  Yeah, I was thinking by all of the binaries. I had forgotten that there's software that bundle it independently of the distro's library. Another comment mentioned docker images, and I've remembered that ruby also bundles it for its own use.
AngeloR 6y ago
I have no idea what a full list looks like.. but the nginx:1.17.10-alpine docker image contains the following: / # nginx -V nginx version: nginx/1.17.10 built by gcc 9.2.0 (Alpine 9.2.0) built with OpenSSL 1.1.1d 10 Sep 2019
- ajp 6y ago
  Mine has a "running with..." part after that. built with OpenSSL 1.1.1d 10 Sep 2019 (running with OpenSSL 1.1.1g 21 Apr 2020)
  - sigotirandolas 6y ago
    If it doesn't print the "running with" line, it's running with the same version it was built with: https://hg.nginx.org/nginx/file/stable-1.18/src/core/nginx.c#l431 https://hg.nginx.org/nginx/file/stable-1.18/src/core/nginx.c...
pmorici 6y ago
Any embedded system that uses a recent version of buildroot and includes openssl. Starting with at least version 2019.02.9
Shorel 6y ago
MySQL

judge2020 6y ago

At least it's just DOS and not anything like heartbleed.

stuff4ben 6y ago

This would primarily affect web servers exposing SSH access to the public right? I suppose it also affects internally accessible servers as well but to a lesser degree in terms of priority.

detaro 6y ago
SSH != SSL. EDIT: Expect web servers running HTTPS in modern configurations to be affected, and other TLS based protocols. SSH is fine.
- chupa-chups 6y ago
  Both SSH and SSL base on TLS. The leak in question has a problem > during or after a TLS 1.3 handshake Sure, openSSL is not SSH, but it is not unreasonable to assume this leak may affect web servers as well (e.g. by being based on the same underlying TLS implementation). "SSH != SSL" is a bit short to invalidate the assumption of the OP. I'd not be so sure this problem does not affect "web server X". https://en.wikipedia.org/wiki/Transport_Layer_Security https://en.wikipedia.org/wiki/Transport_Layer_Security OK, learnt something new today: https://crypto.stackexchange.com/questions/60255/why-doesnt-ssh-use-tls https://crypto.stackexchange.com/questions/60255/why-doesnt-... https://xkcd.com/1053/ https://xkcd.com/1053/ Thanks! :)
  - hannob 6y ago
    > Both SSH and SSL base on TLS No.
    - deleted 6y ago
      [deleted]
  - detaro 6y ago
    The parent is asking if primarily servers exposing "SSH" are affected. I should be less glib though, fair enough. will edit.
  - notaplumber 6y ago

pronoiac 6y ago

Checking out packages.ubuntu.com, it looks like the only version impacted is "focal;" the other versions are too old.

lvs 6y ago
Is there a reason why something as important as openssl is not being backported to keep up with the most recent versions?
- richardwhiuk 6y ago
  Compatibility with other libraries and testing effort. You end up back porting everything. Ubuntu backports the fixes them instead (i.e. Ubuntu's 1.0.2 will be patch with CVE fixes going forward instead of backporting 1.1 wholesale).
  - kakwa_ 6y ago
    Also stability of APIs/ABIs: within a major Ubuntu/Debian version, there is an implicit contract in most cases that if you build something against a library/software provided by the distribution, it will not break after an upgrade of said library/software. To enforce that, a policy of version freeze+backport of bug/security fixes is almost always necessary as very few upstream projects will maintain separate branches and have a clear policy about API/ABI breakages. (OpenSSL is actually somewhat of an exception in that regard).
    - ymse 6y ago
      OpenSSL actually did a breaking API change as recent as 1.1.1e (reverted in 1.1.1f to be fair): https://bugs.python.org/issue40018 https://bugs.python.org/issue40018 And broke the ABI in 1.0.2g: https://bugzilla.redhat.com/show_bug.cgi?id=1313509 https://bugzilla.redhat.com/show_bug.cgi?id=1313509 I don't mean to bash on OpenSSL here and agree they generally do an exceptional job at keeping the public interface stable. Just offering some context. These things are difficult.

snvzz 6y ago

Sure, let's continue to reward incompetence by further funding openssl. In a sane world, everybody would have switched to libressl ages ago.

mlindner 6y ago
LibreSSL has all of the same problems as OpenSSL. It's just a fork from an earlier point in time before OpenSSL did it's big rewrite that came with OpenSSL 1.1.1.
vladsanchez 6y ago
I gather that LibreSSL has an (unintended) OpenSSL dependency? "LibreSSL is composed of four parts: - The openssl(1) utility, which provides tools for managing keys, certificates, etc. - libcrypto: a library of cryptography fundamentals - libssl: a TLS library, backwards-compatible with OpenSSL - libtls: a new TLS library, designed to make it easier to write foolproof application" :shrug:
- notaplumber 6y ago
  No, LibreSSL is a fork of OpenSSL that predates this vulnerability, it even predates the OpenSSL 1.1.x API break (some compatibility has since been added), and has an entirely separate and new TLS 1.3 implementation. https://www.openbsd.org/papers/bsdcan2019-tls13.pdf https://www.openbsd.org/papers/bsdcan2019-tls13.pdf (video: https://www.youtube.com/watch?v=MCVIBwGOwNY https://www.youtube.com/watch?v=MCVIBwGOwNY) It maintains source compatibility with OpenSSL at an API and command-line level (e.g. openssl(1) utility). LibreSSL cannot copy code from later versions of OpenSSL as they relicensed it under the Apache 2.0 license.
pnako 6y ago
The few who switched to LibreSSL actually switched back to OpenSSL (Alpine, HardenedBSD). Void is considering switching back too: https://github.com/void-linux/void-packages/issues/20935 https://github.com/void-linux/void-packages/issues/20935
- 6y ago

nayuki 6y ago

OpenSSL vulnerabilities: The gift that keeps on giving.

takeda 6y ago
I suppose so, but this bug only allows to crash the application. No doubt OpenSSL is buggy, but its problem is that a lot of applications depend on it as well. I'm hoping it will eventually reach status of bind or sendmail, they had also very bad track record, but vulnerabilities now are quite rare.
- nayuki 6y ago
  The article says: "may crash due to a NULL pointer dereference". But in C, dereferencing a null pointer is undefined behavior. Crashing is only one possible outcome, and arguably the best outcome. The compiler and optimizer is entitled to elide certain checks or simplify code under the assumption that a pointer being dereferenced should not be null, and this could lead to dangerous things. Here's an artificial example: int x = 0; int *p; if (...some condition...) p = &x; else p = NULL; print(*p); The compiler is allowed to simplify the code to: int x = 0; int *p; p = &x; print(*p); It's because the 'else' branch must cause a null pointer dereference, so that case can be legally ignored.
  - takeda 6y ago
    I would imagine that if a compiler would be able to make this kind of optimization it would also be able to warn that this is an error. Also optimizers supposed to replace code with a simpler equivalent ones, in your example actually the if statement should block the optimization i.e. if there was no "if", the x would be used directly, and the pointer was ignored. Here's the bug: https://svnweb.freebsd.org/base/releng/12.1/crypto/openssl/ssl/t1_lib.c?r1=352546&r2=360150&pathrev=360150 https://svnweb.freebsd.org/base/releng/12.1/crypto/openssl/s... Value NULL is generally (void *)0 (could be different on different architectures, but it supposed to point to invalid value in memory, so when that memory address is accessed it will trigger segmentation fault.

vladsanchez 6y ago

OpenSSL is the culprit of a MacPort installation issue (vde2) for which there is no maintainer. It exposes operational vulnerability to unmaintained open source software.

Avamander 6y ago
Lets be fair, unmaintained proprietary software has the same vulnerability.
saagarjha 6y ago
This looks like it should be vde2's problem, not OpenSSL's: https://lists.macports.org/pipermail/macports-users/2019-October/047482.html https://lists.macports.org/pipermail/macports-users/2019-Oct...
geofft 6y ago
Just to make sure I understand - you're saying that because OpenSSL is under active maintenance and vde2 is not, OpenSSL is in the wrong? If you want to use unmaintained software, you know OpenSSL 1.0 still exists in this world, right?

agumonkey 6y ago

Now I know why arch pushed a new version this afternoon.

codewiz 6y ago

Is BoringSSL affected?

ccktlmazeltov 6y ago
or LibreSSL?
- notaplumber 6y ago
  No. LibreSSL fork predates the issue, and has its own TLS 1.3 implementation. I'd expect the situation to be similar with Google's BoringSSL, but I don't how closely they track OpenSSL, if at all.

usr1106 6y ago

So how widely TLS 1.3 is a) used b) enabled in either client or server?