The bug, which is officially referenced as CVE-2014-0160, makes it possible for attackers to recover up to 64 kilobytes of memory from the server or client computer running a vulnerable OpenSSL version

This bit needs to be emphasised. The bug doesn't allow you to grab private keys. It allows you to grab a small chunk of memory from the target. This *might* contain private keys, or nuclear launch codes, but it's just as likely (or more likely, depending on your level of paranoia) that it contains junk, or is empty.

(I haven't seen anything that notes if it allows an attacker to control the memory chunk it reads, or if it's arbitrary, which would change things up a bit).

So OpenTLS had a decade-old security flaw, and open source-enthusiasts in that thread told us that anyone who knew what they were doing wasn't using it and that OpenSSL was the way to go.

Oops.

You mean GnuTLS (for the first one).

This one shouldn't be as embarrassing, since it doesn't sound as absurdly simple as the GnuTLS one, nor has it existed for the entire history of OpenSSL (again, unlike the GnuTLS one)... but only by comparison. The article is a bit short on detail of the actual vulnerability (going to have to check other sources...), but it sounds pretty horrible.

So who's next? I believe we've still got Microsoft's, as well as NSS from Mozilla. I believe Go's encryption support is entirely custom as well. Any other widely used crypto libraries that haven't had a horrible failing recently?

Edit: Just as an FYI for Debian users, there's an update if you're using Wheezy security updates (Squeeze is too old, and Jessie/Sid are both still vulnerable).

The bug, which is officially referenced as CVE-2014-0160, makes it possible for attackers to recover up to 64 kilobytes of memory from the server or client computer running a vulnerable OpenSSL version

This bit needs to be emphasised. The bug doesn't allow you to grab private keys. It allows you to grab a small chunk of memory from the target. This *might* contain private keys, or nuclear launch codes, but it's just as likely (or more likely, depending on your level of paranoia) that it contains junk, or is empty.

(I haven't seen anything that notes if it allows an attacker to control the memory chunk it reads, or if it's arbitrary, which would change things up a bit).

Your reading is certainly one reasonable interpretation. But let's not forget the quote from the researchers who discovered the bug. To wit:

"We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication."

The bug, which is officially referenced as CVE-2014-0160, makes it possible for attackers to recover up to 64 kilobytes of memory from the server or client computer running a vulnerable OpenSSL version

This bit needs to be emphasised. The bug doesn't allow you to grab private keys. It allows you to grab a small chunk of memory from the target. This *might* contain private keys, or nuclear launch codes, but it's just as likely (or more likely, depending on your level of paranoia) that it contains junk, or is empty.

(I haven't seen anything that notes if it allows an attacker to control the memory chunk it reads, or if it's arbitrary, which would change things up a bit).

Your reading is certainly one reasonable interpretation. But let's not forget the quote from the researchers who discovered the bug. To wit:

"We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication."

It seems to me security researchers have a lot to gain by over-hyping their own discoveries. Nonetheless, **perhaps** the memory chunk varies between attacks, thus getting the key is inevitable given enough attempts..

Your reading is certainly one reasonable interpretation. But let's not forget the quote from the researchers who discovered the bug. To wit:

"We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication."

Ah I missed that quote (is that on the Torproject blog? I'm not able to visit it at work :-/ ). So it seems like they must have some sort of control over which memory is read, in which case I can see why it's so serious.

I realize the jokes about the NSA are (mostly) tongue in cheek - but is there any way to audit how this vulnerability was introduced? Was it accidental? Who was responsible? It seems that basic audibility of the code base would be critical given that so many rely on this library for secure communications.

The bug, which is officially referenced as CVE-2014-0160, makes it possible for attackers to recover up to 64 kilobytes of memory from the server or client computer running a vulnerable OpenSSL version

This bit needs to be emphasised. The bug doesn't allow you to grab private keys. It allows you to grab a small chunk of memory from the target. This *might* contain private keys, or nuclear launch codes, but it's just as likely (or more likely, depending on your level of paranoia) that it contains junk, or is empty.

(I haven't seen anything that notes if it allows an attacker to control the memory chunk it reads, or if it's arbitrary, which would change things up a bit).

The article did say the researchers were able to attack themselves from the outside using no privileged information and recover "the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication". Unless you want to assume they're lying, that seems pretty devastating.

Whether or not the attacker is able to control which memory chunk it reads, it's obviously an exploitable hole in practice. Just contemplating the fallout from this gives me heartburn, and I'm not even a sysadmin. Given that the attack leaves no log traces, I don't see any way to safely handle this besides getting the patch out there and then revoking and reissuing every certificate and credential. And even then, there's no guarantee the attacker wasn't able to install some kind of backdoor while they had access.

OpenSSL also ships in a wide variety of operating systems and applications, including the Debian Wheezy, Ubuntu, CENTOS, Fedora, OpenBSD, FreeBSD, and OpenSUSE distributions of Linux.

Honest question: does the vulnerable version of OpenSSL ship with these distros? It seems like 1.0.1 through 1.0.1f is a pretty small slice of the OpenSSL spectrum, particularly considering the vendor-backported binaries released by a lot of these guys. So the likelihood of any given web server actually running a version with the vulnerability may be pretty slim, though I'm just trying to optimistically speculate here.

The bug, which is officially referenced as CVE-2014-0160, makes it possible for attackers to recover up to 64 kilobytes of memory from the server or client computer running a vulnerable OpenSSL version

This bit needs to be emphasised. The bug doesn't allow you to grab private keys. It allows you to grab a small chunk of memory from the target. This *might* contain private keys, or nuclear launch codes, but it's just as likely (or more likely, depending on your level of paranoia) that it contains junk, or is empty.

(I haven't seen anything that notes if it allows an attacker to control the memory chunk it reads, or if it's arbitrary, which would change things up a bit).

The article did say the researchers were able to attack themselves from the outside using no privileged information and recover "the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication". Unless you want to assume they're lying, that seems pretty devastating.

Whether or not the attacker is able to control which memory chunk it reads, it's obviously an exploitable hole in practice. Just contemplating the fallout from this gives me heartburn, and I'm not even a sysadmin. Given that the attack leaves no log traces, I don't see any way to safely handle this besides getting the patch out there and then revoking and reissuing every certificate and credential. And even then, there's no guarantee the attacker wasn't able to install some kind of backdoor while they had access.

Edit: Ninja-ed.

I wonder how it is that it leaves no trace? Clearly information has to be sent out from the vulnerable server for the attacker to get it. Is there just no way to distinguish it from normal traffic?

OpenSSL also ships in a wide variety of operating systems and applications, including the Debian Wheezy, Ubuntu, CENTOS, Fedora, OpenBSD, FreeBSD, and OpenSUSE distributions of Linux.

Honest question: does the vulnerable version of OpenSSL ship with these distros? It seems like 1.0.1 through 1.0.1f is a pretty small slice of the OpenSSL spectrum, particularly considering the vendor-backported binaries released by a lot of these guys. So the likelihood of any given web server actually running a version with the vulnerability may be pretty slim, though I'm just trying to optimistically speculate here.

The bug, which is officially referenced as CVE-2014-0160, makes it possible for attackers to recover up to 64 kilobytes of memory from the server or client computer running a vulnerable OpenSSL version

This bit needs to be emphasised. The bug doesn't allow you to grab private keys. It allows you to grab a small chunk of memory from the target. This *might* contain private keys, or nuclear launch codes, but it's just as likely (or more likely, depending on your level of paranoia) that it contains junk, or is empty.

(I haven't seen anything that notes if it allows an attacker to control the memory chunk it reads, or if it's arbitrary, which would change things up a bit).

The article did say the researchers were able to attack themselves from the outside using no privileged information and recover "the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication". Unless you want to assume they're lying, that seems pretty devastating.

Whether or not the attacker is able to control which memory chunk it reads, it's obviously an exploitable hole in practice. Just contemplating the fallout from this gives me heartburn, and I'm not even a sysadmin. Given that the attack leaves no log traces, I don't see any way to safely handle this besides getting the patch out there and then revoking and reissuing every certificate and credential. And even then, there's no guarantee the attacker wasn't able to install some kind of backdoor while they had access.

Edit: Ninja-ed.

It doesn't seem like they'd be able to install a backdoor this way, perhaps only if they get very lucky with the uns/pws they intercept.

The bug, which is officially referenced as CVE-2014-0160, makes it possible for attackers to recover up to 64 kilobytes of memory from the server or client computer running a vulnerable OpenSSL version

This bit needs to be emphasised. The bug doesn't allow you to grab private keys. It allows you to grab a small chunk of memory from the target. This *might* contain private keys, or nuclear launch codes, but it's just as likely (or more likely, depending on your level of paranoia) that it contains junk, or is empty.

(I haven't seen anything that notes if it allows an attacker to control the memory chunk it reads, or if it's arbitrary, which would change things up a bit).

The article did say the researchers were able to attack themselves from the outside using no privileged information and recover "the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication". Unless you want to assume they're lying, that seems pretty devastating.

Whether or not the attacker is able to control which memory chunk it reads, it's obviously an exploitable hole in practice. Just contemplating the fallout from this gives me heartburn, and I'm not even a sysadmin. Given that the attack leaves no log traces, I don't see any way to safely handle this besides getting the patch out there and then revoking and reissuing every certificate and credential. And even then, there's no guarantee the attacker wasn't able to install some kind of backdoor while they had access.

Edit: Ninja-ed.

I wonder how it is that it leaves no trace? Clearly information has to be sent out from the vulnerable server for the attacker to get it. Is there just no way to distinguish it from normal traffic?

If it's a man-in-the-middle then the attacker already has access to the info, they're tapping the wire. No need to touch the server aside from reading the key. The diagram used for the article suggests it is a MITM.

Edit: it's not MITM, it's a direct attack on the server as pointed out by KitsuneKnight .

I realize the jokes about the NSA are (mostly) tongue in cheek - but is there any way to audit how this vulnerability was introduced? Was it accidental? Who was responsible? It seems that basic audibility of the code base would be critical given that so many rely on this library for secure communications.

The bug, which is officially referenced as CVE-2014-0160, makes it possible for attackers to recover up to 64 kilobytes of memory from the server or client computer running a vulnerable OpenSSL version

This bit needs to be emphasised. The bug doesn't allow you to grab private keys. It allows you to grab a small chunk of memory from the target. This *might* contain private keys, or nuclear launch codes, but it's just as likely (or more likely, depending on your level of paranoia) that it contains junk, or is empty.

(I haven't seen anything that notes if it allows an attacker to control the memory chunk it reads, or if it's arbitrary, which would change things up a bit).

The article did say the researchers were able to attack themselves from the outside using no privileged information and recover "the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication". Unless you want to assume they're lying, that seems pretty devastating.

Whether or not the attacker is able to control which memory chunk it reads, it's obviously an exploitable hole in practice. Just contemplating the fallout from this gives me heartburn, and I'm not even a sysadmin. Given that the attack leaves no log traces, I don't see any way to safely handle this besides getting the patch out there and then revoking and reissuing every certificate and credential. And even then, there's no guarantee the attacker wasn't able to install some kind of backdoor while they had access.

Edit: Ninja-ed.

I wonder how it is that it leaves no trace? Clearly information has to be sent out from the vulnerable server for the attacker to get it. Is there just no way to distinguish it from normal traffic?

If it's a man-in-the-middle then the attacker already has access to the info, they're tapping the wire. No need to touch the server aside from reading the key. The diagram used for the article suggests it is a MITM.

Hmm.. so is this actually a side-channel attack? How exactly is server or client-internal memory ending up in packets sent out over the network?

The more I work with software I realize that the very nature of code makes it vulnerable without a real solution. A door can be build to withstand force, software is more like the matrix, that you can bend when you use your mind. There is no physical barrier in software. Only a mental one. So as long as you are smarter than the designer you will get in. I think there is a possibility that in 10 years or so, software becomes too vulnerable, and we will have to stop using it. Because we cant protect it anymore. Its not very likely, the arms race is going ok currently, but who knows? I sure hope we have a Battlestar Galactica then .

The bug, which is officially referenced as CVE-2014-0160, makes it possible for attackers to recover up to 64 kilobytes of memory from the server or client computer running a vulnerable OpenSSL version

This bit needs to be emphasised. The bug doesn't allow you to grab private keys. It allows you to grab a small chunk of memory from the target. This *might* contain private keys, or nuclear launch codes, but it's just as likely (or more likely, depending on your level of paranoia) that it contains junk, or is empty.

(I haven't seen anything that notes if it allows an attacker to control the memory chunk it reads, or if it's arbitrary, which would change things up a bit).

The article did say the researchers were able to attack themselves from the outside using no privileged information and recover "the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication". Unless you want to assume they're lying, that seems pretty devastating.

Whether or not the attacker is able to control which memory chunk it reads, it's obviously an exploitable hole in practice. Just contemplating the fallout from this gives me heartburn, and I'm not even a sysadmin. Given that the attack leaves no log traces, I don't see any way to safely handle this besides getting the patch out there and then revoking and reissuing every certificate and credential. And even then, there's no guarantee the attacker wasn't able to install some kind of backdoor while they had access.

Edit: Ninja-ed.

I wonder how it is that it leaves no trace? Clearly information has to be sent out from the vulnerable server for the attacker to get it. Is there just no way to distinguish it from normal traffic?

If it's a man-in-the-middle then the attacker already has access to the info, they're tapping the wire. No need to touch the server aside from reading the key. The diagram used for the article suggests it is a MITM.

Hmm.. so is this actually a side-channel attack? How exactly is server or client-internal memory ending up in packets sent out over the network?

I'm assuming it's because of a memory overflow... some random bytes that aren't supposed to be there are in the payload. I recommend reading this for more information:http://heartbleed.com/edit: heartbleed is the name of the bug apparently.

The bug, which is officially referenced as CVE-2014-0160, makes it possible for attackers to recover up to 64 kilobytes of memory from the server or client computer running a vulnerable OpenSSL version

This bit needs to be emphasised. The bug doesn't allow you to grab private keys. It allows you to grab a small chunk of memory from the target. This *might* contain private keys, or nuclear launch codes, but it's just as likely (or more likely, depending on your level of paranoia) that it contains junk, or is empty.

(I haven't seen anything that notes if it allows an attacker to control the memory chunk it reads, or if it's arbitrary, which would change things up a bit).

The article did say the researchers were able to attack themselves from the outside using no privileged information and recover "the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication". Unless you want to assume they're lying, that seems pretty devastating.

Whether or not the attacker is able to control which memory chunk it reads, it's obviously an exploitable hole in practice. Just contemplating the fallout from this gives me heartburn, and I'm not even a sysadmin. Given that the attack leaves no log traces, I don't see any way to safely handle this besides getting the patch out there and then revoking and reissuing every certificate and credential. And even then, there's no guarantee the attacker wasn't able to install some kind of backdoor while they had access.

Edit: Ninja-ed.

I wonder how it is that it leaves no trace? Clearly information has to be sent out from the vulnerable server for the attacker to get it. Is there just no way to distinguish it from normal traffic?

If it's a man-in-the-middle then the attacker already has access to the info, they're tapping the wire. No need to touch the server aside from reading the key. The diagram used for the article suggests it is a MITM.

The Heartbleed bug is not a man-in-the-middle attack. It exploit's OpenSSL's handling of TLS's heartbeat, which is an encrypted portion of the connection. The reason it leaves no traces is not because it can't be detected, but because it's just not logged by OpenSSL. Theoretically it could be logged (though there might be enough false positives that it's not helpful... I've not found out whether that's the case or not yet, though)..

Attackers apparently also have control (or at least influence) over what 64KB of memory they can capture, and can keep requesting more memory with each heartbeat (so the 64KB limit isn't that limiting).

Heartbeat can be disabled in OpenSSL, but only via a recompile (in which case you might as well apply the patch).

The bug, which is officially referenced as CVE-2014-0160, makes it possible for attackers to recover up to 64 kilobytes of memory from the server or client computer running a vulnerable OpenSSL version

This bit needs to be emphasised. The bug doesn't allow you to grab private keys. It allows you to grab a small chunk of memory from the target. This *might* contain private keys, or nuclear launch codes, but it's just as likely (or more likely, depending on your level of paranoia) that it contains junk, or is empty.

(I haven't seen anything that notes if it allows an attacker to control the memory chunk it reads, or if it's arbitrary, which would change things up a bit).

The article did say the researchers were able to attack themselves from the outside using no privileged information and recover "the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication". Unless you want to assume they're lying, that seems pretty devastating.

Whether or not the attacker is able to control which memory chunk it reads, it's obviously an exploitable hole in practice. Just contemplating the fallout from this gives me heartburn, and I'm not even a sysadmin. Given that the attack leaves no log traces, I don't see any way to safely handle this besides getting the patch out there and then revoking and reissuing every certificate and credential. And even then, there's no guarantee the attacker wasn't able to install some kind of backdoor while they had access.

Edit: Ninja-ed.

I wonder how it is that it leaves no trace? Clearly information has to be sent out from the vulnerable server for the attacker to get it. Is there just no way to distinguish it from normal traffic?

If it's a man-in-the-middle then the attacker already has access to the info, they're tapping the wire. No need to touch the server aside from reading the key. The diagram used for the article suggests it is a MITM.

The Heartbleed bug is not a man-in-the-middle attack. It exploit's OpenSSL's handling of TLS's heartbeat, which is an encrypted portion of the connection. The reason it leaves no traces is not because it can't be detected, but because it's just not logged by OpenSSL. Theoretically it could be logged (though there might be enough false positives that it's not helpful... I've not found out whether that's the case or not yet, though)..

Attackers apparently also have control (or at least influence) over what 64KB of memory they can capture, and can keep requesting more memory with each heartbeat (so the 64KB limit isn't that limiting).

Heartbeat can be disabled in OpenSSL, but only via a recompile (in which case you might as well apply the patch).

Interesting. I assume you'd still need to be a man-in-the-middle however, to exploit the bug once you've the private key.

edit: although obviously once the private key is exposed, security is pretty much gone.

Interesting. I assume you'd still need to be a man-in-the-middle however, to exploit the bug once you've the private key.

Once you have the private key, yes. Or you could use this attack to scoop up other data directly from the server process (such as credentials people have recently used to login, or a page containing sensitive data that's about to be sent to a user). The more I read, the more horrifying this vulnerability is. I'd say it definitely trumps the GnuTLS one in horrible-ness (although not in facepalm-ness).

The bug, which is officially referenced as CVE-2014-0160, makes it possible for attackers to recover up to 64 kilobytes of memory from the server or client computer running a vulnerable OpenSSL version

This bit needs to be emphasised. The bug doesn't allow you to grab private keys. It allows you to grab a small chunk of memory from the target. This *might* contain private keys, or nuclear launch codes, but it's just as likely (or more likely, depending on your level of paranoia) that it contains junk, or is empty.

(I haven't seen anything that notes if it allows an attacker to control the memory chunk it reads, or if it's arbitrary, which would change things up a bit).

Your reading is certainly one reasonable interpretation. But let's not forget the quote from the researchers who discovered the bug. To wit:

"We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication."

From their website:

Quote:

Q: Can attacker access only 64k of the memory?

A: There is no total of 64 kilobytes limitation to the attack, that limit applies only to a single heartbeat. Attacker can either keep reconnecting or during an active TLS connection keep requesting arbitrary number of 64 kilobyte chunks of memory content until enough secrets are revealed.

We're FUCKED.

Why? Because this compromizes not just the keys of the sites you've trusted and your own sites if you've used OpenSSL to connect to them.

It compromizes everything you ever sent, if somebody was savvy enough (i.e. your traffic was high-value enough) to record it in case "SOME DAY" that data becomes decryptable. SOME DAY is now, and recording of all high-value data can be presumed to have commenced.

The truly bad thing is that a disturbingly large number of programmers know this one weird little trick to secure their data: you just transmit it over SSL and then it is secure because nobody can look at it.

It compromizes everything you ever sent, if somebody was savvy enough (i.e. your traffic was high-value enough) to record it in case "SOME DAY" that data becomes decryptable. SOME DAY is now, and recording of all high-value data can be presumed to have commenced.

If Perfect-Forward Security was not used? Yup, screwed. If PFS was used? Your sessions from before the private key was stolen are still completely safe. Your sessions after the private key was stolen are only vulnerable to an active man in the middle attack (the attacker isn't just recording the data, but actively modifying it. Your sessions, with PFS, even after the private key was stolen are still just as immune to a passive MITM attack.

A group like the NSA might be able to record a huge amount of data, but it makes it absurdly more difficult (as in, orders of magnitude more so) if they have to actively MITM every session in real time. They can't just decrypt-on demand, but have to throw a huge amount of CPU power into it as well.