Hacker News new | ask | show | jobs
by nwallin 2161 days 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.

2 comments

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

I believe the state of the art in generic malloc implementations has improved since this sort of thing was commonplace, though.