
OpenSSL high-severity bug – affects 1.1.1d, 1.1.1e, 1.1.1f - AngeloR
https://www.openssl.org/news/secadv/20200421.txt
======
9wzYQbTYsAIc
> 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.

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

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

~~~
erichdongubler
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
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.

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

~~~
lvs
Is there a reason why something as important as openssl is not being
backported to keep up with the most recent versions?

~~~
richardwhiuk
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_
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
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.

~~~
tialaramex
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...

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

------
codewiz
Is BoringSSL affected?

~~~
ccktlmazeltov
or LibreSSL?

~~~
notaplumber
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
So how widely TLS 1.3 is

a) used

b) enabled in either client or server?

------
nayuki
OpenSSL vulnerabilities: The gift that keeps on giving.

~~~
takeda
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
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
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...](https://svnweb.freebsd.org/base/releng/12.1/crypto/openssl/ssl/t1_lib.c?r1=352546&r2=360150&pathrev=360150)

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.

------
stuff4ben
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
SSH != SSL. EDIT: Expect web servers running HTTPS in modern configurations to
be affected, and other TLS based protocols. SSH is fine.

~~~
chupa-chups
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-...](https://crypto.stackexchange.com/questions/60255/why-doesnt-ssh-
use-tls)

[https://xkcd.com/1053/](https://xkcd.com/1053/)

Thanks! :)

~~~
hannob
> Both SSH and SSL base on TLS

No.

------
vladsanchez
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.

~~~
geofft
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?

------
snvzz
Sure, let's continue to reward incompetence by further funding openssl.

In a sane world, everybody would have switched to libressl ages ago.

~~~
pnako
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)

~~~
ccktlmazeltov
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 .

~~~
CameronNemo
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.

~~~
notaplumber
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](https://marc.info/?l=openbsd-ports-
cvs&m=158411843726544&w=2)

~~~
CameronNemo
>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.

[https://github.com/void-linux/void-
packages/pull/15310](https://github.com/void-linux/void-packages/pull/15310)

