> 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.
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.
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).
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...
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.
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:
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.
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.
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.
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".
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.
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.
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"
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.
2 week turnaround time, not bad I guess, for something found by a static analyzer.