5 ms·

I'm glad there have been changes to the project. Heartbleed was certainly bad, but I personally never understood getting behind LibreSSL. Seeing one bad vulnera

I'm glad there have been changes to the project. Heartbleed was certainly bad, but I personally never understood getting behind LibreSSL. Seeing one bad vulnerability from an established project and immediately jumping ship to a brand new one with less eyes and reputation seemed hasty to me.

sigstoat 6y ago
> jumping ship to a brand new one with less eyes and reputation That doesn't sound like an accurate description of LibreSSL, what with it being a part of OpenBSD.
- easterncalculus 6y ago
  This is a fair point, but it is being used as standard on other operating systems. I remember people switching to Void Linux en masse after they made it their standard mostly as a result of Heartbleed.
  - sigstoat 6y ago
    > but it is being used as standard on other operating systems ...so even more people are looking at it? not sure what problem you think is happening here.
    - my123 6y ago
      Note that Windows ships with LibreSSL since a while too. (present in System32/LibreSSL on remotely modern Windows 10 installs, OpenSSH relies on it among other things)
      - protomyth 6y ago
        MacOS Catalina 10.15.6 /usr/bin/openssl version LibreSSL 2.8.3
uluyol 6y ago
As the LibreSSL devs have said, heartbleed was not the cause of the fork. They forked the project because they believed the OpenSSL project repeatedly made bad decisions. From https://www.openbsd.org/papers/eurobsdcon2014-libressl.html https://www.openbsd.org/papers/eurobsdcon2014-libressl.html > Heartbleed can't even be considered the worst OpenSSL vuln. Previous bugs have resulted in remote code execution. Anybody remember the Slapper worm? That worm exploited an OpenSSL bug (which was apparently titled the SSLv2 client master key buffer overflow) which revealed not only encrypted data or your private key, but also gave up a remote shell on the server, and then it propogated itself. Yeah, I'd say that's worse. But no headlines. > I mention this just to reinforce that LibreSSL is not the result of "the worst bug ever". I may call you dirty names, but I'm not going to fork your project on the basis of a missing bounds check. > why fork > Instead, libressl is here because of a tragic comedy of other errors. Let's start with the obvious. Why were heartbeats, a feature only useful for the DTLS protocol over UDP, built into the TLS protocol that runs over TCP? And why was this entirely useless feature enabled by default? Then there's some nonsense with the buffer allocator and freelists and exploit mitigation countermeasures, and we keep on digging and we keep on not liking what we're seeing. Bob's talk has all the gory details. You can see "Bob's talk" here: https://www.openbsd.org/papers/bsdcan14-libressl/ https://www.openbsd.org/papers/bsdcan14-libressl/ though I think there is a YouTube video somewhere. Also I would like to point out that Google also forked OpenSSL. So it seems that the LibreSSL folks are not the only ones who thought a fork was necessary.
- evh 6y ago
  > though I think there is a YouTube video somewhere "LibreSSL with Bob Beck" at https://www.youtube.com/watch?v=GnBbhXBDmwU https://www.youtube.com/watch?v=GnBbhXBDmwU
  - dijit 6y ago
    I seem to recall him giving a live feed of his findings while spelunking into the codebase. I think I actually got grey hairs from that... Then I realised that OpenSSL is quite entrenched, I'm still running it to this day, in production.
  - 6y ago
raverbashing 6y ago
Read this (from older to newer posts) https://opensslrampage.org/ https://opensslrampage.org/ it explains a lot of the bad stuff on OpenSSL Example: "“Do you really want to build OpenSSL for 16-bit Windows? Well, we don’t.”" https://opensslrampage.org/post/83952304402/do-you-really-want-to-build-openssl-for-16-bit https://opensslrampage.org/post/83952304402/do-you-really-wa...
kzrdude 6y ago
Eyes doesn't make a project, but the development process
nwallin 6y ago
It wasn't about one bad vulnerability. Heartbleed was just the last straw. OpenSSL implemented its own memory management system instead of using malloc. It would allocate one pool of memory and then manipulate into that. This meant that static analysis, runtime analysis, fuzzers were incapable of finding memory bugs. Because all pointers into that pool were "valid". LibreSSL stripped out OpenSSL's memory system and replaced it with malloc() and free() as provided by libc. Suddenly, static analysis, valgrind, and fuzzers found something like 3 dozen memory errors. That is bad on so many levels. OpenSSL supports big endian x86_64. OpenSSL supports EBDIC paths, certs, encodings, etc. OpenSSL supports DOS and Windows for Workgroups 3.11. It had a config -D NO_OLD_ASN1 and NO_ASN1_OLD. These defs performed different things. Having more eyeballs on a project didn't help OpenSSL, because all of those eyeballs glazed over immediately and/or had forks stabbed into them. In something like the first month, the LibreSSL project deleted something like 90,000 LOC and 60,000 lines of comments/whitespace. Not changed: deleted. Removed useless cruft like mentioned above, and dangerous cruft like SSL 3.0 support. The latest OpenSSL tarball is 9.4MB, the latest LibreSSL tarball is 3.6MB. It has fewer eyeballs, sure, but it's an order of magnitude easier to audit.
- chasil 6y ago
  OpenBSD also changed it's malloc implementation from sbrk to mmap, the net effect being that free returned memory to the OS far more often. It broke a lot of interesting stuff.
- caf 6y ago
  Custom allocators are (or were) common enough that Valgrind includes an API for them to use to tell the analysis engine where the valid memory blocks are: https://valgrind.org/docs/manual/mc-manual.html#mc-manual.mempools https://valgrind.org/docs/manual/mc-manual.html#mc-manual.me... I believe the state of the art in generic malloc implementations has improved since this sort of thing was commonplace, though.

sigstoat 6y ago

> jumping ship to a brand new one with less eyes and reputation That doesn't sound like an accurate description of LibreSSL, what with it being a part of OpenBSD.

easterncalculus 6y ago
This is a fair point, but it is being used as standard on other operating systems. I remember people switching to Void Linux en masse after they made it their standard mostly as a result of Heartbleed.
- sigstoat 6y ago
  > but it is being used as standard on other operating systems ...so even more people are looking at it? not sure what problem you think is happening here.
  - my123 6y ago
    Note that Windows ships with LibreSSL since a while too. (present in System32/LibreSSL on remotely modern Windows 10 installs, OpenSSH relies on it among other things)
    - protomyth 6y ago
      MacOS Catalina 10.15.6 /usr/bin/openssl version LibreSSL 2.8.3

uluyol 6y ago

As the LibreSSL devs have said, heartbleed was not the cause of the fork. They forked the project because they believed the OpenSSL project repeatedly made bad decisions. From https://www.openbsd.org/papers/eurobsdcon2014-libressl.html https://www.openbsd.org/papers/eurobsdcon2014-libressl.html > Heartbleed can't even be considered the worst OpenSSL vuln. Previous bugs have resulted in remote code execution. Anybody remember the Slapper worm? That worm exploited an OpenSSL bug (which was apparently titled the SSLv2 client master key buffer overflow) which revealed not only encrypted data or your private key, but also gave up a remote shell on the server, and then it propogated itself. Yeah, I'd say that's worse. But no headlines. > I mention this just to reinforce that LibreSSL is not the result of "the worst bug ever". I may call you dirty names, but I'm not going to fork your project on the basis of a missing bounds check. > why fork > Instead, libressl is here because of a tragic comedy of other errors. Let's start with the obvious. Why were heartbeats, a feature only useful for the DTLS protocol over UDP, built into the TLS protocol that runs over TCP? And why was this entirely useless feature enabled by default? Then there's some nonsense with the buffer allocator and freelists and exploit mitigation countermeasures, and we keep on digging and we keep on not liking what we're seeing. Bob's talk has all the gory details. You can see "Bob's talk" here: https://www.openbsd.org/papers/bsdcan14-libressl/ https://www.openbsd.org/papers/bsdcan14-libressl/ though I think there is a YouTube video somewhere. Also I would like to point out that Google also forked OpenSSL. So it seems that the LibreSSL folks are not the only ones who thought a fork was necessary.

evh 6y ago
> though I think there is a YouTube video somewhere "LibreSSL with Bob Beck" at https://www.youtube.com/watch?v=GnBbhXBDmwU https://www.youtube.com/watch?v=GnBbhXBDmwU
- dijit 6y ago
  I seem to recall him giving a live feed of his findings while spelunking into the codebase. I think I actually got grey hairs from that... Then I realised that OpenSSL is quite entrenched, I'm still running it to this day, in production.
- 6y ago

raverbashing 6y ago

Read this (from older to newer posts) https://opensslrampage.org/ https://opensslrampage.org/ it explains a lot of the bad stuff on OpenSSL Example: "“Do you really want to build OpenSSL for 16-bit Windows? Well, we don’t.”" https://opensslrampage.org/post/83952304402/do-you-really-want-to-build-openssl-for-16-bit https://opensslrampage.org/post/83952304402/do-you-really-wa...

kzrdude 6y ago

Eyes doesn't make a project, but the development process

nwallin 6y ago

It wasn't about one bad vulnerability. Heartbleed was just the last straw. OpenSSL implemented its own memory management system instead of using malloc. It would allocate one pool of memory and then manipulate into that. This meant that static analysis, runtime analysis, fuzzers were incapable of finding memory bugs. Because all pointers into that pool were "valid". LibreSSL stripped out OpenSSL's memory system and replaced it with malloc() and free() as provided by libc. Suddenly, static analysis, valgrind, and fuzzers found something like 3 dozen memory errors. That is bad on so many levels. OpenSSL supports big endian x86_64. OpenSSL supports EBDIC paths, certs, encodings, etc. OpenSSL supports DOS and Windows for Workgroups 3.11. It had a config -D NO_OLD_ASN1 and NO_ASN1_OLD. These defs performed different things. Having more eyeballs on a project didn't help OpenSSL, because all of those eyeballs glazed over immediately and/or had forks stabbed into them. In something like the first month, the LibreSSL project deleted something like 90,000 LOC and 60,000 lines of comments/whitespace. Not changed: deleted. Removed useless cruft like mentioned above, and dangerous cruft like SSL 3.0 support. The latest OpenSSL tarball is 9.4MB, the latest LibreSSL tarball is 3.6MB. It has fewer eyeballs, sure, but it's an order of magnitude easier to audit.

chasil 6y ago
OpenBSD also changed it's malloc implementation from sbrk to mmap, the net effect being that free returned memory to the OS far more often. It broke a lot of interesting stuff.
caf 6y ago
Custom allocators are (or were) common enough that Valgrind includes an API for them to use to tell the analysis engine where the valid memory blocks are: https://valgrind.org/docs/manual/mc-manual.html#mc-manual.mempools https://valgrind.org/docs/manual/mc-manual.html#mc-manual.me... I believe the state of the art in generic malloc implementations has improved since this sort of thing was commonplace, though.