OpenSSL high-severity bug – affects 1.1.1d, 1.1.1e, 1.1.1f
openssl.org> 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.
At least it's just DOS and not anything like heartbleed.
What popular software contain these vulnerable versions of the OpenSSL library?
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.
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.
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 2019Mine 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)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...
Any embedded system that uses a recent version of buildroot and includes openssl. Starting with at least version 2019.02.9
MySQL
Checking out packages.ubuntu.com, it looks like the only version impacted is "focal;" the other versions are too old.
Is there a reason why something as important as openssl is not being backported to keep up with the most recent versions?
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).
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).
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
And broke the ABI in 1.0.2g:
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.
To be fair "these things are difficult" if your ABI is terribly designed.
If you've used modern libpng you can thank people like me for the fact you don't need to recompile or even sometimes rewrite code after every micro version release.
Example of something libpng did before we "gently" explained that it's stupid: re-order the public data structures in a "bug fix" release. Because the old order looked untidy see, and so long as every program is recompiled with the new version of the library it won't break...
Now I know why arch pushed a new version this afternoon.
Is BoringSSL affected?
or LibreSSL?
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.
So how widely TLS 1.3 is
a) used
b) enabled in either client or server?
OpenSSL vulnerabilities: The gift that keeps on giving.
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.
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:
The compiler is allowed to simplify the code to:int x = 0; int *p; if (...some condition...) p = &x; else p = NULL; print(*p);
It's because the 'else' branch must cause a null pointer dereference, so that case can be legally ignored.int x = 0; int *p; p = &x; print(*p);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/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.
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.
SSH != SSL. EDIT: Expect web servers running HTTPS in modern configurations to be affected, and other TLS based protocols. SSH is fine.
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
OK, learnt something new today: https://crypto.stackexchange.com/questions/60255/why-doesnt-...
Thanks! :)
> Both SSH and SSL base on TLS.
You are very mistaken. OpenSSH only uses OpenSSL (or LibreSSL) as an optional dependency for the libcrypto primitives (RSA/AES etc). NOT for libssl.
The SSH protocol has nothing to do with either SSL or TLS.
> Both SSH and SSL base on TLS
No.
The parent is asking if primarily servers exposing "SSH" are affected. I should be less glib though, fair enough. will edit.
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.
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?
This looks like it should be vde2's problem, not OpenSSL's: https://lists.macports.org/pipermail/macports-users/2019-Oct...
Lets be fair, unmaintained proprietary software has the same vulnerability.
Sure, let's continue to reward incompetence by further funding openssl.
In a sane world, everybody would have switched to libressl ages 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
Their logic is a bit weird to me, I would definitely choose a fork from professional that re-write everything with a security perspective, over a bad library trying to be hardened .
The Void conundrum is that most software does not support LibreSSL's APIs, and that is especially rough because Void is rolling release. OpenBSD does not write patches for the latest Qt release, so people with little crypto experience have to write those patches.
Which is a bizarre statement, all ports development happens on the OpenBSD -current branch, which is effectively a rolling release for developers/users running snapshots.
All of those projects that switched were simply expecting LibreSSL/OpenBSD to upstream support, when it hasn't got nearly the same numbers of developers.
Also, there were other problems with updating Qt on OpenBSD, but that was resolved. It is maintained by a single developer.
https://marc.info/?l=openbsd-ports-cvs&m=158411843726544&w=2
>rolling release for developers/users running snapshots
Well Void is far more on edge than OpenBSD -current.
>there were other problems with updating Qt on OpenBSD, but that was resolved
They are still trailing us.
LibreSSL did not rewrite everything... Look at the code, most of it's identical to what's in OpenSSL. It's a fork, not a rewrite.
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.
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:
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 (video: 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.