ELI5: Open SSL Bug

I'm seeing a lot about this but am unable to pinpoint the specific impact is has on me, and what precautions to take as a result. Can someone dumb down the issue please?


Comments


[16 Points] the_avid:

OpenSSL is a cryptography library that implements the features behind the padlock in your browser and a ton of other places (like secure email, remote desktop servers) for both the server and the client.

It is used absolutely everywhere because it is the standard cryptography library. You likely can't make a request on the internet or with a phone today without passing through openssl somewhere in the process.

This bug was in a new feature called 'heartbeat' which has been out for around 2 years now. You might remember that a few years ago there was a large movement to get websites like GMail, Hotmail and Facebook etc. to be HTTPS (that is, padlocked) by default since it is a secure practice. The reason why the service providers erred and waited on implementing this instead of doing it from the beginning is that setting up a secure connection is computationally expensive.

If you requires 5,000 servers to serve your users with plain HTTP (no padlock), it might require you 7,000 servers to serve the same users with HTTPS (with padlock), so a lot of large website put the decision off.

What OpenSSL did to help them is implement the heartbeat feature. Here is what it does: normally when you first visit a site it does a handshake and establishes the padlock - this involves passing keys back and forward and verifying signatures, it all happens without the user seeing it. Normally after 10 or 20 seconds of inactivity if that user then went back to the same page and refreshed it or checked their emails again (or messages) it would go through the entire handshake procedure again. The handshake procedure was the most computationally expensive part of the process.

The idea with heartbeat was that you do the handshake once when a user first visits the site, and then every 5 or 10 seconds the client would send a 'heartbeat' message to let the server know they are still there. Think about it for sites like Gmail: most users keep Gmail open all day and it is a secure connection. Without heartbeat the client would check for new emails every 30 seconds and it would have to go through the handshake/initiation procedure every single time, which is expensive on the servers. With heartbeat, they do the handshake once and then they can keep the connection alive potentially forever (as long as the server keeps getting the messages).

The way heartbeat would work is the client would come up with some random data and send it to the server as part of the heartbeat message. To verify that it received the message, the server would take the same random data and send it back to the client.

The bug came up not in how the protocol was designed, but in how it was implemented. What was happening was that the server was constructing the response to the client without checking that what the client sent with the random data was of the correct length.

The way the exploit works is that the client asks the server to respond to a heartbeat and it tells it its random data is longer than it actually is, when the server responds when it goes to read back the same random data it exceeds its length and reads into its own memory - sending that data back to the client (up to 64KB).

The problem is that the memory in the computer is where all sorts of things are stored - private keys, session information, etc. And with each exploit heartbeat request you can get back a different part of the memory, and you're almost assured to get back some sensitive data.

The implication for Tor is both in clients and in relays - both need to be updated urgently. There is an implication for clients because even though they don't act as servers, they still have the server code in the openssl library and an advanced attacker can trick the Tor client into running that code.

edit i've spent some time actually testing this exploit against my own test hidden service and reading the source. I think the chances of a hidden service being completely compromised and located using this exploit are zero, the chances of the private key being taken are close to zero, the chance of some useless circuit information being exposed is more likely. I just did tens of thousands of requests against a test vulnerable hidden service and came back with nothing. looking at the code and how memory is allocated also backs up this finding that private keys are safe. I think its almost certain that some people, like governments, had access to this exploit previously but whats most likely is that it couldn't be used to break tor. The bigger worry for Tor is the client - if you can get a vulnerable user to route/visit a server that exploits it them it could spit out memory from your machine, which might be more interesting than what a hidden service gets back.

I think it was good for the Tor project to overestimate the potential impact, and while this bug is one of the worst in years for the clearnet - it isn't a 'sky is falling' moment for Tor.


[2 Points] obsidianchao:

There's no precautions to take. This bug affects the servers, not the client, which means the only way to protect yourself is to get the fuck off the internet. But we both know that won't happen.

The best thing you can do is check if services are affected by it before using them (there's lists, you can probably just find them through Google). Hopefully most places update their OpenSSL code before some real bad shit happens.