Slashdot Mirror
Heartbleed OpenSSL Vulnerability: A Technical Remediation
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."
Was this badly translated from another language, or have I been out of system administration too long?
To be fair, nobody knows if this was exploited in the wild or not already - so the "mess" was going to happen anyway (unless you planned to patch your server, assuming your certificate was still good, and not tell any of your users that their passwords may have been exposed in the last couple years).
I'm running Linux Mint Olivia -- the next to current version -- an no openssl patch is yet available as of this afternoon. I image there are quite a few similar distros. Since I have actual work to do, and can't risk wasting two hours on a potentially borked upgrade, I'm stuck to trying not to use programs affected by the exploit for the duration.
While something tells me this exploit is somewhat overblown, what really ticks me off is that this is all the result of delegating memory management to C pointers and basically mmap. As far as I'm concerned, in this day and age, that amounts to spaghetti code and I can't say it endears me to the reliability of openssl.
Please, we need SSL to be secure, not fast. Just use a less efficient method to make things more secure.
May the Maths Be with you!
Ok, I read the wrong link from up above. This article does say as you claimed, and my above post is nonsense. :)
Except now pretty much every affected machine needs to have its SSL certificates and private keys revoked and trashed, and new keys/certificates issued.
In the meantime, thousands (if not millions) of sites leaked sensitive data to anyone who wanted to snoop on it.
Yeah, no big deal, none at all...no repercussions will come of this.
Theo claims OpenBSD is unaffected. http://undeadly.org/cgi?action...
Theo claims OpenSSH is unaffected, because it isn't. OpenSSL, even on OpenBSD, is quite affected.
There is well written C, and there is poorly written C. I've been through the bowels of OpenSSL, and there are parts of it that frighten me. Ninety percent of the issues in OpenSSL could be solved by adopting a modern coding style and using better static analysis. While static analysis tools can't find vulnerabilities, they can root out code smell that hides vulnerabilities. If, for instance, I followed the advice of two of the quality commercial static analyzers that I ran against the OpenSSL code base, I would have been forced to refactor the code in such a way that this bug would have either been obvious to anyone casually reviewing it, if the refactor did not eliminate the bug all together.
C and C++ are not necessarily the problem. It's true that higher level languages solve this particular kind of vulnerability, but they are not safe from other vulnerabilities. To solve problems like these, we need better coding style in critical open source projects.
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/
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.
It's worse than that. Most browsers don't check certificate revocation lists, 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. 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.
For people who didn't follow the link chain, it has since been updated:
Important update (10th April 2014): Original content of this blog entry stated that one of our SeaCat server detected Heartbleed bug attack prior its actual disclosure. EFF correctly pointed out that there are other tools, that can produce the same pattern in the SeaCat server log (see http://blog.erratasec.com/2014... ). I don't have any hard data evidence to support or reject this statement. Since there is a risk that our finding is false positive, I have modified this entry to neutral tone, removing any conclusions. There are real honeypots in the Internet that should provide final evidence when Heartbleed has been broadly exploited for a first time.
I work for a large financial organization. While fixing the hole itself was easy- having to tell a bunch (I can't even legally give you a ballpark, but its a lot) of customers to change their passwords (or forcing them to change) is very bad PR. Plus we don't know if any financial data was accessed. The data could literally bankrupt very large companies or my own company. This is no small problem!
Not really. Lots of people are wrong on the internets! :-)
Sleep your way to a whiter smile...date a dentist!
Can you please tell me where the passwords are in this memory dump ...
Have you ever seen a real exploited piece of data?
These are taken from Yahoo production servers, a day or two ago:
http://cdn.arstechnica.net/wp-...
http://cdn.arstechnica.net/wp-...
Can you guess where the password is, now? (And those didn't even take that many tries)
I have not seen actual SSL private keys floating around just yet, but given that the original researchers said they managed to get private keys from their own servers, I think it is reasonable to assume that some production servers must have already leaked them.