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?
We have to thank the security researchers that chose to break the embargo on the news before OpenSSL coordinated with downstream project.
Thank you for the mess, guys!
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!
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.
Some versions are. The OpenVPN appliance I was running was affected, and there were no updates for it this morning so I had to kill it.
https://security.stackexchange...
I read somewhere that there is a TLS flag you can use in the config to disable the affected code, but for the life of me I can't find it for this post. :(
-- This sig is only a test. If this were a real sig it would say something witty. --
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.
I think if you had enabled the tls-auth option it prevents the attack.
It's not easy to fix leaked data.
You can revoke keys, change passwords, and patch the software, but you can't revoke the data that was already sent with them (and can now be decoded) no more than you can you revoke the bits of data that could have been stolen.
trivial? excellent then you can show us how to trivially identify what data has been leaked/exposed and what needs to be reported to the various authorities that require reports on exposed privacy data.
I think you completely missed my point. The hand wringing is useless. Fix it, mitigate it, and try to move on. Any damage that has been done is one. All that cane be done now is to patch and mitigate. All the wrangling going on on the 'net is amusing. The past can't be changed. We can learn from it and move on. There are plenty of ways to stop the bleeding. People are acting like the sky is falling. It's truly sad that you're one of them.
Qualys SSL Test is including a flag for Heartbleed vulnerability and auto-fails any domain tested that is affected.
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.
There have been a number of sites.
SSLLabs scanner has been updated to check for Heartbleed, and also will report when the cert validity starts (handy if you want to see whether they're using a new cert). https://www.ssllabs.com/ssltes...
LastPass has a pretty decent scanner that just focuses on Heartbleed (without all the other info that you get from SSLLabs): https://lastpass.com/heartblee...
There are some others out there as well, of course.
There's even one for client-side testing (almost as critical):
Pacemaker is an awesome little POC script (python 2.x) for testing whether a *client* is vulnerable (many that use OpenSSL are...). https://github.com/Lekensteyn/...
There's no place I could be, since I've found Serenity...
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.
One of my current roles is to provide technical support/advice for a group of project managers and business analysts. This morning a few of them had watched the Crash News Network over breakfast and came in convinced that privacy, as we know it, had come to an end. My job is to talk them off the ledge (and I actually enjoy it, they're smart people and as long as I explain it correctly, they get it... I've found that's pretty rare).
1. The issue only exposes 64k at a time. Let's assume that the average enterprise application has at least a 1G footprint (and that's actually on the low end of most applications I work with). That's 1,048,576K. At best, this means that this exploit can access 0.006% of memory of an applications memory at one time.
Ahh you say, I will simple make 16,667 requests and I will retrieve all the memory used by the application.
2. The entire basis of this issue is that programs reuse memory blocks. The function loadAllSecrects may allocate a 64k block, free it and then that same block is used by the heartbeat code in question. However, this code will also release this same block which means that the block is free for use again. Chances are very good (with well optimized code), that the heartbeat will be issued the same 64k block of memory on the next call. Multi-threaded/multi-client apps perturb this but the upshot is that it's NOT possible to directly walk all of the memory used by an application with this exploit. You can make a bazillion calls and you will never get the entire memory space back. (You're thinking of arguments to contrary, your wrong... you wont.)
Congratulations, much success... you have 64k internet.
3. Can you please tell me where the passwords are in this memory dump:
k/IsZAEZFgZueWNuZXQxFzAVBgNVBAMTDk5ZQ05FVC1ST09ULUNBMB4XDTEwMDMw
MzIyNTUyOFoXDTIwMDMwMzIyMTAwNVowMDEWMBQGCgmSJomT8ixkARkWBm55Y25l
There will be contextual clues (obvious email addresses, usernames, etc) but unless you know the structure of the data, a lot of time will be spent with brute force deciphering. Even if you knew for a fact that they were using Java 7 build 51 and Bouncy Castle 1.50, you still don't know if the data you pulled down is using a BC data structure or a custom defined one and you aren't sure where the boundaries start and end. The fact that data structures may or may not be contiguous complicates matters. A Java List does not have to store all members consecutively or on set boundaries (by design, this is what distinguishes it from a Vector).
Long story short. Yes, there is a weakness here. However, it's very hard to _practically_ exploit... especially on a large scale (no one is going to use this to walk away with the passwords for every gmail account... they'd be very, very lucky to pull a few dozen).
This doesn't excuse developers from proper programming practices. It's just putting "Heartbleed" in perspective.
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!
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.