Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What changed in OpenSSL after heartbleed

arxiv.org

Post reply on HN
Print view View original

31–40 of 65 posts

Re: What changed in OpenSSL after heartbleed

#31

Post by nwallin »

easterncalculus wrote: post #4

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.

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.

Re: What changed in OpenSSL after heartbleed

#32

Post by hoistbypetard »

icefo wrote: post #20
uluyol wrote: post #13

Earlier quoted context omitted.

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 > 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 bu…

Damn OpenSSL sounds a lot worse than I thought after reading those slides. The custom malloc, the function that allow you to jump anywhere in OpenSSL, the 17 layer deep IFDef, the dubious entropy that openSSL try to generate if the OS doesn't provide it, the bugs that sit in the issue tracker for years. A lot of that uglyness seems to come from the fact that OpenSSL wants to support all environments (even DOS). I won…

0. At least a couple did, but they were pretty niche-y. (Void was one, I think?)

1. It's a ton of packaging work even if the API/ABI were compatible (Calling it compatible is a bit of a stretch IMO).

2. One of the things LibreSSL removes is the FIPS validated stuff. Distributions that harbor ambitions of being used in large US corporate and government installations want that.

3. By the time the portable LibreSSL build system came out, there were already significant improvements afoot within the OpenSSL project.

I'm sure there are other reasons, but those are the big ones I'm aware of.

Re: What changed in OpenSSL after heartbleed

#33

Post by protomyth »

my123 wrote: post #27
sigstoat wrote: post #15

Earlier quoted context omitted.

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

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)

MacOS Catalina 10.15.6

  /usr/bin/openssl version
  LibreSSL 2.8.3

Re: What changed in OpenSSL after heartbleed

#34

Post by icefo »

CameronNemo wrote: post #30
icefo wrote: post #20

Earlier quoted context omitted.

Damn OpenSSL sounds a lot worse than I thought after reading those slides. The custom malloc, the function that allow you to jump anywhere in OpenSSL, the 17 layer deep IFDef, the dubious entropy that openSSL try to generate if the OS doesn't provide it, the bugs that sit in the issue tracker for years. A lot of that uglyness seems to come from the fact that OpenSSL wants to support all environments (even DOS). I won…

>LibreSSL was made to be API/ABI compatible with openSSL and target a POSIX OS LibreSSL is neither API compatible with newer OpenSSL versions, nor is it ABI compatible. In fact, they break ABI every six months. Furthermore LibreSSL upstream only targets OpenBSD, with the portable version existing as an afterthought. The only linux distribution using LibreSSL is Void Linux (Alpine switched to OpenSSL some time ago). E…

Thank you ! That was interesting read. The main problems with LibreSSL are software compatibility since most software only build against OpenSSL and performance because the portable version doesn't include optimisations for other platforms than x86_64

The slides came out in 2014 so the API / ABI thing was probably true then but not anymore.

Maybe things would have been different if LibreSSL was backed by a major Linux distribution and OpenBSD. Even then Unix/Linux is not the only target of a lot of software and I doubt a lot of developer would have put the time to support both.

[Edit] I just saw in an other comment that LibreSSL is used in MacOSX and windows for openSSH. Maybe developers will consider it if it becomes available on major platforms

Re: What changed in OpenSSL after heartbleed

#35

Post by riffraff »

yjftsjthsd-h wrote: post #26
icefo wrote: post #3

This made me think of BoringSSL and LibreSSL again. Looking up on Wikipedia it seems that LibreSSL is focused on OpenBSD and removed lots of legacy code. BoringSSL (Google) got renamed to Tink but I couldn't not find much more. It's sad to see that duplication of effort but it's also the force of open source

> It's sad to see that duplication of effort but it's also the force of open source How's that a FOSS thing? Do you think there would be fewer TLS implementations running around if they were proprietary?

IIUC the point was that the ability to fork projects (and then potentially merge back) is one of the strengths of OSS, even if it means some duplicated effort.

Re: What changed in OpenSSL after heartbleed

#36

Post by protomyth »

evh wrote: post #17
uluyol wrote: post #13

Earlier quoted context omitted.

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 > 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 bu…

> though I think there is a YouTube video somewhere "LibreSSL with Bob Beck" at https://www.youtube.com/watch?v=GnBbhXBDmwU

Big-endian Support for AMD64 - the explanation from the person in the crowd is something of a horror story that I think a lot of have witnessed in various forms.

https://youtu.be/GnBbhXBDmwU?t=2330

Re: What changed in OpenSSL after heartbleed

#37

Post by Sohcahtoa82 »

icefo wrote: post #20
uluyol wrote: post #13

Earlier quoted context omitted.

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 > 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 bu…

Damn OpenSSL sounds a lot worse than I thought after reading those slides. The custom malloc, the function that allow you to jump anywhere in OpenSSL, the 17 layer deep IFDef, the dubious entropy that openSSL try to generate if the OS doesn't provide it, the bugs that sit in the issue tracker for years. A lot of that uglyness seems to come from the fact that OpenSSL wants to support all environments (even DOS). I won…

> A lot of that uglyness seems to come from the fact that OpenSSL wants to support all environments (even DOS).

Someone correct me if I'm wrong, but I seem to remember either BoringSSL or LibreSSL (or both?) saying that their fork removed support for DOS because not only did almost nobody use it, but it didn't even work anyways.

Re: What changed in OpenSSL after heartbleed

#38

Post by Mountain_Skies »

juanbyrge wrote: post #21

Code quality and hygiene mean absolutely nothing if you have a large number of academic types who use OpenSSL as the dumping ground for their pet research projects, that are enabled by default, of course. Also, OpenSSL supports all kinds of ancient esoteric platforms that are essentially unused, yet were kept in the code base for sentimental reasons. The real metric they should be looking at is the number of features…

During a code review we found recently written Go code using SHA1, which has been functionally obsolete since 2005. It's a bit baffling why Google even included it in Go or at the very least didn't make it throw up a bunch of warnings to only use it for very special edge cases related to backward compatibility.

The developer didn't know what algorithm to pick so he just went with one at random, assuming it was ok since it was in the library. How many other security vulnerabilities are out there due to similar circumstances? It's a bit troubling.

Re: What changed in OpenSSL after heartbleed

#39

Post by marcinzm »

rshnotsecure wrote: post #18

OpenSSL recently passed a change in their vuln announcement policy to give a major firm, which everyone here knows I think, 7 days advance notice of any zero-day that they were made aware of. This was the engineer who helped set up the new policy: https://awe.com To be honest, maybe it's a good idea. It depends on how much support Huawei is willing to give OpenSSL.

So, being realistic here, that means the Chinese government is given 7 days advance notice?

Re: What changed in OpenSSL after heartbleed

#40

Post by DyslexicAtheist »

guidovranken wrote: post #24
zdw wrote: post #7

I'd be more interested in a comparison in the strategies used to harden the codebase in the forks like BoringSSL and LibreSSL, and how well those strategies have panned out. There has historically been some crowing from the LibreSSL crowd about how their work avoided CVE's later discovered in OpenSSL: https://undeadly.org/cgi?action=article&sid=20150319145126

I've been doing differential fuzzing of many major cryptographic libraries. It currently tests symmetric crypto, some elliptic curve crypto, bignum arithmetic, message digests and MACs, KDFs, but not TLS, X509, ASN1 etc (yet). The list of bugs it has found so far can be viewed here [1]. The bug count per library can not be used as an absolute metric and not all bugs are security vulnerabilities (though many can be un…

> but not TLS, X509, ASN1 etc (yet)

then this may interest you:

https://blog.doyensec.com/2020/05/14/asn1fuzz.html

^^ ASN1 is really the bees-knees for fuzzing telecoms protocols in UMTS/LTE/5G etc and doesn't get enough love in other domains. It's a high learning curve but once you get beyond the "standardese" language in the docs it's opening doors to opportunities in so many industries.

> BoringSSL has fewer bugs than LibreSSL, which has fewer bugs than OpenSSL. One of the reasons for this could be that the bug count is proportional to the complexity/SLOC

the openSSL codebase is notorious but I think it's also because it has been in existing for so long. if I look around today I see 2 camps: cryptographers and software engineers. letting sw-engineers do crypto is usually a bad idea but it's often worse when cryptographers start coding. it's almost like a variation of the old joke of "the 2 most dangerous things in Tech are a sw-engineer with a soldering iron and a hw-engineer with a sw-patch" ... apart from complexity leading to bugs I'd also say there is another downside which is stronger in openssl: people end up using it wrongly which makes it a proverbial foot-gun for implenters.

> [1] https://github.com/guidovranken/cryptofuzz

very cool thanks!!

Post reply on HN