2 week turnaround time, not bad I guess, for something found by a static analyzer.
/ # 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 built with OpenSSL 1.1.1d 10 Sep 2019 (running with OpenSSL 1.1.1g 21 Apr 2020)https://hg.nginx.org/nginx/file/stable-1.18/src/core/nginx.c...
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).
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).
a) used
b) enabled in either client or server?
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 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);
int x = 0;
int *p;
p = &x;
print(*p);
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.
> 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! :)
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.
If you want to use unmaintained software, you know OpenSSL 1.0 still exists in this world, right?
In a sane world, everybody would have switched to libressl ages ago.
Void is considering switching back too: https://github.com/void-linux/void-packages/issues/20935
"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:
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.