STE WILLIAMS

The “heartbleed” bug in OpenSSL has caused a right kerfuffle.

I shan’t re-visit the bug in detail (here’s a full explanation), but this is typically what happens:

• Malicious person makes an encrypted (TLS) connection to your server.
• Malicious person sends what’s called a heartbeat request, instead of real data, to tell your server to keep the connection alive.
• Malicious person sends a only few bytes in the request, but claims he sent you 65535 bytes.

The heartbeat system is supposed to work by copying the incoming request data into a reply packet, and sending it back so the other end can see that the connection is working correctly.

But buggy versions of OpenSSL reply like this:

• Copy 65535 bytes into the reply, starting at the bytes of data in the incoming request, but overflowing the input buffer.
• Send back all 65535 bytes, including the original request data plus whatever happens to be nearby in RAM on your server.

→ The value 65535 is the biggest number (hexadecimal 0xFFFF) you can represent in 16 bits, or two bytes, which is the size allocated for the request length field in the TLS heartbeat protocol. Remember the old 64KB limit? Here it is, all over again.

This is a buffer overflow, but not the sort you’re probably used to.

Instead of sending too much data, to trick the other end into crashing and executing your data as code, you send too little data and trick the other end into making up for the missing data by leaking some of its own.

And ever since news of the bug went public, intrepid (inquisitive? insatiable? incorrigible?) researchers have been hammering on web servers all over the world, sending “heartbleed” packets and monitoring, 64KB at a time, just how interesting that leaked data seems to be.

As you can imagine, a lot of it is very dull, but you can keep on “heartbleeding” a vulnerable server until exciting data fragments turn up.

Indeed, researchers claim to have found all sorts of stuff they shouldn’t have seen, such as usernames, passwords, server encryption keys, and more.

So although your passwords probably weren’t exposed because of this bug, they possibly were, in just the same way that although you didn’t win the lottery this week, someone did.

That means that some writers are urging you to change all your passwords, just in case.

The argument is, “Why not?”

After all, if you swiped your credit card in a payment machine that you later felt uneasy about, you’d probably consider cancelling the card and asking your bank for a new one, without waiting to see if fraudulent transactions appeared.

Changing your online passwords is trivial in comparison, the argument goes, so it makes even more sense from a proactive point of view.

However, there is one important reason why you might not want to rush out and change all your passwords on all your services right this minute, and it’s a sort-of Catch-22.

If you need to change your password on a server that is at risk due to heartbleed, then the new password you choose may be at risk due to heartbleed.

And it’s fair to say that there are a lot more people ready to heartbleed your new password right now than there were a week, a month or a year ago when you set the old password up.

We suggest you wait until you know that a site is not vulnerable, for example because it makes a clear statement to that effect, or use a public testing service that connects to a website to estimate whether it’s safe or not first.

→ Note that remotely testing a website for “heartbleed” (or testing an email server, or any application than accepts TLS or HTTPS connections) can’t give a complete answer. The servers operated by a company that uses Microsoft IIS, for example, won’t be vulnerable. But if the company also outsources the operation of mirror servers to a third party, those mirrors might be affected. So you could be at risk some of the time, but not all of it, depending on which server is chosen each time you visit.

In short: by all means get ready to change all your passwords.

But avoid changing them until you have a good reason to think that the services protected by those passwords do not have the heartbleed vulnerability.

Also, consider adopting Two Factor Authentication (2FA) wherever you can.

2FA systems generally use a sequence of one-time codes to make stolen passwords much less useful to cybercrooks.

Here’s why…

Listen now:

Listen later:

Follow @duckblog

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/F_R0Oo1DW-s/