Heartbleed OpenSSL Vulnerability: A Technical Remediation 239
An anonymous reader writes "Since the announcement malicious actors have been leaking software library data and using one of the several provided PoC codes to attack the massive amount of services available on the internet. One of the more complicated issues is that the OpenSSL patches were not in-line with the upstream of large Linux flavors. We have had a opportunity to review the behavior of the exploit and have come up with the following IDS signatures to be deployed for detection."
Re:What version does OpenBSD use? (Score:5, Interesting)
That's good post. I'm going to blatantly copypaste it because Theo gets to the crux of why Openssl is terrible:
From: Theo de Raadt cvs.openbsd.org>
Subject: Re: FYA: http://heartbleed.com/ [heartbleed.com]
Newsgroups: gmane.os.openbsd.misc
Date: 2014-04-08 19:40:56 GMT (1 day, 6 hours and 15 minutes ago)
> On Tue, Apr 08, 2014 at 15:09, Mike Small wrote:
> > nobody gmail.com> writes:
> >
> >> "read overrun, so ASLR won't save you"
> >
> > What if malloc's "G" option were turned on? You know, assuming the
> > subset of the worlds' programs you use is good enough to run with that.
>
> No. OpenSSL has exploit mitigation countermeasures to make sure it's
> exploitable.
What Ted is saying may sound like a joke...
So years ago we added exploit mitigations counter measures to libc
malloc and mmap, so that a variety of bugs can be exposed. Such
memory accesses will cause an immediate crash, or even a core dump,
then the bug can be analyed, and fixed forever.
Some other debugging toolkits get them too. To a large extent these
come with almost no performance cost.
But around that time OpenSSL adds a wrapper around malloc & free so
that the library will cache memory on it's own, and not free it to the
protective malloc.
You can find the comment in their sources ...
#ifndef OPENSSL_NO_BUF_FREELISTS /* On some platforms, malloc() performance is bad enough that you can't just
OH, because SOME platforms have slow performance, it means even if you
build protective technology into malloc() and free(), it will be
ineffective. On ALL PLATFORMS, because that option is the default,
and Ted's tests show you can't turn it off because they haven't tested
without it in ages.
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.
OpenSSL is not developed by a responsible team.
Re:Situation is a Shambles (Score:5, Interesting)
This is not a memory management issue per se, and has nothing to do with mmap or malloc. In fact, the malloc succeeds just fine. Rather than just explaining in text, it might be easier if i simplify the issue in C parlance (this would look neater if slashdot allowed better code formatting):
char *rec_p = record;
uint16_t rec_len = SSL3_RECORD_LEN;
uint16_t user_len = *(uint16_t*)rec_p;
rec_p += sizeof(uint16_t);
char *buf = malloc(user_len);
memcpy(buf, rec_p, user_len);
reply(buf);
Due to the fact that this code works more or less exactly as designed, the exploit functions across architectures and operating systems. This bug is so amateurish, i almost find it difficult to believe that it was unintentional.
Re:Mountain out of a molehill (Score:5, Interesting)
It's worse than that. Most browsers don't check certificate revocation lists [spiderlabs.com], and the certificate authority might not have a CRL infrastructure in place that can support the number of revoked certs generated by this incident.
Granted, they could take the money they receive from all the reissued certificates and use it to build such an infrastructure, but they probably won't.
Web-SSL was already a broken system [theregister.co.uk]. Now that it's been cracked open even wider, maybe we can throw it out and implement something better.
Oh, who am i kidding? We'll just pretend everything's okay again after most people have patched the hole.
Re:Situation is a Shambles (Score:3, Interesting)
This is not a memory management issue per se, and has nothing to do with mmap or malloc.
But what the grandparent post said still applies. It's how C treats memory via pointers. The issue, from looking at the code you posted, is that memcpy() copies from beyond the length of rec_p. In a sane language that doesn't treat memory as free-for-all, this isn't possible.
Due to the fact that this code works more or less exactly as designed, the exploit functions across architectures and operating systems. This bug is so amateurish, i almost find it difficult to believe that it was unintentional.
It's the kind of mistake programmers make all the time in C. Sure, you can tell me battle-hardened, conscientious, professional programmers wouldn't make this mistake. Whatever, we've seen this kind of thing too many times for this sentiment to mean anything practically useful.
Re:Thank you for the mess (Score:5, Interesting)
Yes, there are some people who are incapable of compiling their own software who will have to wait until the patch comes through. Those people shouldn't be managing security for a large website (or any website really, in an ideal world).
Nonsense. I'd want only vendor supplied fixes applied, unless the vendor is so slow as to be incompetent (but then, why would you be using them?)
Why? Because user applied fixes tend to be forgotten, and if the library isn't managed by the package system (you've uninstalled the package you're overwriting, right?) you might miss subsequent important updates.
An example from a far from fuckwitted user:
http://marc.info/?l=sqlite-use... [marc.info]
Yes, the author of the SQLite library fell pray to this very issue. Let the package manager track packages.
Of course, you could also build binary packages from source, but then that assumes the upstream source packages have been patched, or you're happy to patch the source packages yourself.
Re:Situation is a Shambles (Score:4, Interesting)
Add to that the fact that interpreters are generally written by expert programmers, and then they receive lots and lots of testing and debugging, and then (hopefully) become mature/stable shortly thereafter; whereas application code is often written by mediocre programmers and often receives only minimal testing and debugging.
I'd wager that most of those writing/maintaining OpenSSL are not only expert programmers, but, overall, are more security concious than the authors/maintainers of interpreters. You point would be completely valid if the topic was some builitin board / wiki / chat program / etc. Sadly, that's not the case at hand.