OpenSSL high-severity bug – affects 1.1.1d, 1.1.1e, 1.1.1f (opens in new tab)

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.

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)

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

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.

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.

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! :)

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 .

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.