Theo De Raadt's Small Rant On OpenSSL

New submitter raides (881987) writes "Theo De Raadt has been on a better roll as of late. Since his rant about FreeBSD playing catch up, he has something to say about OpenSSL. It is worth the 5 second read because it is how a few thousand of us feel about the whole thing and the stupidity that caused this panic." Update: 04/10 15:20 GMT by U L : Reader badger.foo pointed out Ted Unangst (the Ted in the mailing list post) wrote two posts on the issue: "heartbleed vs malloc.conf and "analysis of openssl freelist reuse" for those seeking more detail.

Comments

Re:Summary.

[bluefoxlucid]

I can see his point; however he's still wrong. Mostly because he's Theo, though I'll credit he seems to have quietly accepted some of the things he was wrong about in the past.

So then a bug shows up which leaks the content of memory mishandled by that layer. If the memoory had been properly returned via free, it would likely have been handed to munmap, and triggered a daemon crash instead of leaking your keys.

And then the five servers in the world running OpenBSD would be safe.

The moment the bug was discovered, we were all fucked. The bug would have gone out readily. This particular abuse wasn't tested, obviously, or someone would have gone, "Wow look at that! It gave back a chunk of data LOL! Let's fix that before relase!" So if they would have satisfied Theo, OpenSSL still wouldn't have been tested and wouldn't have crashed, and would be released vulnerable.

That release gets on every SSL-enabled server, including into products like SonicWall VPN and firewalls. These are vulnerable--I've tested them here, the exploit actually works. FortiNet's products--FortiMail, FortiGate--these are vulnerable. CentOS 6 is vulnerable. Debian is vulnerable. Ubuntu since forever is vulnerable. Fedora is vulnerable. SuSE is vulnerable. A bunch of shit on Windows is vulnerable.

Then we realize there's a bug.

Let's talk about someone else who's wrong: the OpenSSL team. The OpenSSL developers are pissed off because of the full disclosure practice that put this bug out there before a patch was released. They think responsible disclosure would be better. So you disclose responsibly, and the patches come out. Some hackers see new OpenSSL release, and look into it. They see malloc() fixes in networking code, or you put up a big "THIS IS A SECURITY PATCH" notice.

Start your engines, motherfuckers.

Distros start rebuilding immediately because there's an automatic trigger, and because they know already: there's a huge network nobody knows about made up of distro maintainers and upstream programmers all sharing security and bugfix information. Ubuntu's devs were ready for this shit before it was released, and probably would have had packages built before the source went out. Debian, RedHat, SuSE.

Twelve hours later, sysadmins start noticing.

By then, someone has reverse-engineered the patches. The moment packages start propagating, the source files are up--SRPMs are out. By the time you can see and react, someone sees "SECURITY FIX", reads the diff, the best ones can do an exploit in half an hour for something like this. You might be hacked before you notice the patch.

So it would be better with responsible disclosure. The problem is this isn't a hack you'd see: you don't know if you're hacked. You wake up and your security is now handled by Schrodinger's Cat: your SSL keys are secure or not secure, and you don't know until you shake down the blackhats who have your keys, and maybe they bury the information when you do that so you still don't know. Not only that, but maybe blackhats secretly had the hack before it was noticed by a security researcher--that's rather common.

The moment this thing went out, it was too late. Your security is broken. And most people aren't on OpenBSD, so they'd get hacked even with OpenSSL using the system malloc(). They'd get hacked even with OpenBSD's protections, because OpenSSL is running almost always on Linux and OpenBSD's protections aren't on Linux. They'd get hacked anyway. That means everyone.

So no, Theo. You're not helping. You didn't discover the keystone that would save us all. Maybe god damn EVERYONE should implement these protections everywhere; glibc has some, but long reads won't crash glibc unless you hit unmapped.

Congrats Theo, your reputation continues.

Re:Summary.

[bluefoxlucid]

The problem is it would have crashed on OpenBSD if someone would have tested this exploit on OpenBSD, meaning someone would have to be looking for the exploit, meaning someone would have found a bunch of data coming back anyway and gone "oh lol wtf?".

If someone crashed your server trying to exploit it, you would probably not notice; since there aren't many OpenBSD servers, probably nobody would notice that these attacks were happening and gone, "Whoa! A wild 0-day exploit!" And even if they had, there's all these non-OpenBSD servers that are getting hacked and nobody can say if they're hacked or not, so we just get ourselves into this exact situation sooner. We don't come away with smaller collateral damage; EVERY SSL CERTIFICATE EVER ISSUED IS NOW INVALID.

Nothing Theo suggested changes the situation. Implementing malloc() protection everywhere might; but if you can show any ability to beat that protection a percentage of the time, then we're also in the same situation. We're talking about reads, so canaries aren't it. If you're crashing out on reads, then every malloc(1) that crashes if you read 2 requires 4096 bytes of real RAM to store 1 byte of data--we get into costs.