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

OpenSSL high-severity bug – affects 1.1.1d, 1.1.1e, 1.1.1f(openssl.org)

189 points by AngeloR 6 years ago | 45 comments

> 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 6 years ago |

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

nayuki 6 years ago |

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

erichdongubler 6 years 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 6 years 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 6 years 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 6 years 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)

pmorici 6 years ago | |

Any embedded system that uses a recent version of buildroot and includes openssl. Starting with at least version 2019.02.9

Shorel 6 years ago | |

MySQL

pronoiac 6 years ago |

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

lvs 6 years ago | |

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

richardwhiuk 6 years 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).

agumonkey 6 years ago |

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

codewiz 6 years ago |

Is BoringSSL affected?

ccktlmazeltov 6 years ago | |

or LibreSSL?

notaplumber 6 years 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 6 years ago |

So how widely TLS 1.3 is

a) used

b) enabled in either client or server?

nayuki 6 years ago |

OpenSSL vulnerabilities: The gift that keeps on giving.

takeda 6 years 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 6 years 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.

stuff4ben 6 years 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 6 years 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 6 years 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

OK, learnt something new today: https://crypto.stackexchange.com/questions/60255/why-doesnt-...

https://xkcd.com/1053/

Thanks! :)

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

geofft 6 years 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?

saagarjha 6 years ago | |

This looks like it should be vde2's problem, not OpenSSL's: https://lists.macports.org/pipermail/macports-users/2019-Oct...

Avamander 6 years ago | |

Lets be fair, unmaintained proprietary software has the same vulnerability.

snvzz 6 years ago |

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

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

pnako 6 years 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

ccktlmazeltov 6 years ago | | |

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 .

mlindner 6 years 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 6 years 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 6 years 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 (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.