I've just been discussing with my son exactly what is (seriously) compromised by the Heartbleed bug.
I can understand the basics, it means that something encrypted using SSL (i.e. HTTPS protocol connections) can be decrypted by someone who shouldn't be able to do so.
Having said that what can a 'bad hacker' actually do? There's a sea of packets flowing around the internet, picking out a series of packets relating to one 'connection' (i.e. with related information in them) is non-trivial as far as I can see, unless the hacker is sitting looking at the data flowing through a switch feeding one particular site.
So, it's possible to hack/decrypt a single packet which I suppose *might* contain someone's login details if the username and password was in a single packet. Is this the extent ot the problem?
If there's more to it than this can someone explain. For example MumsNet says it's been hacked as a consequence of this bug, I don't quite understand how someone could get at *all* the login details on MumsNet unless they fortuitously got an administrator's login details and the system is stupid enough to allow an administrator to get at all usernames and unenecrypted passwords.
Surely quite simple (and well known) security practices would make this sort of thing much more difficult:-
Don't send complete Username/Password details in a single packet, easy enough to do by asking for them separately or even crude padding.
Don't store user's details in single, big, unencrypted files.
Don't store unencrypted passwords anywhere, use the Unix login style of things so that what's stored is the result of encrypting the password and is difficult (as in requires loads of processor ooomph) to decrypt by brute force methods.
On Wed, 16 Apr 2014 14:49:21 +0100 Chris Green cl@isbd.net allegedly wrote:
I've just been discussing with my son exactly what is (seriously) compromised by the Heartbleed bug.
I can understand the basics, it means that something encrypted using SSL (i.e. HTTPS protocol connections) can be decrypted by someone who shouldn't be able to do so.
Sorry, but no, you have this wrong.
The heartbleed vulnerability is much nastier that you believe. It alllows reading of arbitrary 64K chunks of memory on any system running an application which is linked against a vulnerable version of openssl. The original "hearbeat" code was meant to allow a client/server interaction of the form "are you still awake?". The bug allowed an attacker to send the heartbeat requests but ask for (and get) up to 64 K of contents of RAM. Continued polling would get continued chunks of memory. So if that chunk of RAM contained sensitive data (as it could) then bang you are dead.
See https://xkcd.com/1354/ for a nice graphical explanation.
Mick ---------------------------------------------------------------------
Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 http://baldric.net
---------------------------------------------------------------------
On Wed, Apr 16, 2014 at 03:06:03PM +0100, mick wrote:
On Wed, 16 Apr 2014 14:49:21 +0100 Chris Green cl@isbd.net allegedly wrote:
I've just been discussing with my son exactly what is (seriously) compromised by the Heartbleed bug.
I can understand the basics, it means that something encrypted using SSL (i.e. HTTPS protocol connections) can be decrypted by someone who shouldn't be able to do so.
Sorry, but no, you have this wrong.
Ah, that would explain why I couldn't understand why it is such a serious vulnerability.
The heartbleed vulnerability is much nastier that you believe. It alllows reading of arbitrary 64K chunks of memory on any system running an application which is linked against a vulnerable version of openssl.
So it's actually an exploit of a specific connection protocol within SSL that's sort of intended for debug/test/admin sort of things?
The original "hearbeat" code was meant to allow aclient/server interaction of the form "are you still awake?". The bug allowed an attacker to send the heartbeat requests but ask for (and get) up to 64 K of contents of RAM. Continued polling would get continued chunks of memory. So if that chunk of RAM contained sensitive data (as it could) then bang you are dead.
So the hacker would simply 'ask' any old system (by sending an SSL packet or sequence of packets) for the contents of its RAM - oooh! I can see that would open up rather more vulnerabilities than just the odd username/login.
On 16/04/14 15:37, Chris Green wrote:
[SNIP]
So the hacker would simply 'ask' any old system (by sending an SSL packet or sequence of packets) for the contents of its RAM - oooh! I can see that would open up rather more vulnerabilities than just the odd username/login.
AIUI, the rogue request is not the designated length, but short. The responding server always replies with 64K, and it pads the response with random chunks of RAM. These can be examined, and it is possible to extract username and password information from it.
Therefore, it is pretty pointless rushing off to changes ones passwords until the server has been patched, or the new password can be sniffed out in just the same way as the old one could.
Cheers, Laurie.
On Thu, Apr 17, 2014 at 10:55:37AM +0100, Laurie Brown wrote:
On 16/04/14 15:37, Chris Green wrote:
[SNIP]
So the hacker would simply 'ask' any old system (by sending an SSL packet or sequence of packets) for the contents of its RAM - oooh! I can see that would open up rather more vulnerabilities than just the odd username/login.
AIUI, the rogue request is not the designated length, but short. The responding server always replies with 64K, and it pads the response with random chunks of RAM. These can be examined, and it is possible to extract username and password information from it.
Therefore, it is pretty pointless rushing off to changes ones passwords until the server has been patched, or the new password can be sniffed out in just the same way as the old one could.
Bad design putting username and password adjacent in memory, if they weren't there together it would be much more difficult to use the bug to extract useful information. It shouldn't be necessary for both to be there at the same time at all.
In fact why are lists of this sort of information even *present* on web facing servers? Surely the web server should authenticate against non-web facing machines where, if necessary, customer details are stored.
On 17 April 2014 10:55, Laurie Brown laurie@brownowl.com wrote:
AIUI, the rogue request is not the designated length, but short.
I believe the request basically says "respond with the 64k string 'xx'", where 'xx' clearly isn't 64k in length and the server responds with 64k of data starting with the 'xx' but followed by whatever else it had in memory after those characters.
As Mick said, the XKCD link is very good, so I'll repeat it: https://xkcd.com/1354/ For anyone familiar with XKCD it's worth noting that this isn't just a funny comment on the situation, but actually a very good explanation of what the problem is.
Therefore, it is pretty pointless rushing off to changes ones passwords until the server has been patched, or the new password can be sniffed out in just the same way as the old one could.
Indeed, although it also highlights why having the same password for multiple sites is a very bad idea.
You can probably expect your bank to fix a vulnerability like this pretty quickly, but that forum you signed up to once upon a time to access something that you've never been back to since, but where you used the same password? That's the main lesson here, I think (although hopefully for "lesson" read "reminder").
On 17/04/14 11:12, Mark Rogers wrote:
As Mick said, the XKCD link is very good, so I'll repeat it: https://xkcd.com/1354/ For anyone familiar with XKCD it's worth noting that this isn't just a funny comment on the situation, but actually a very good explanation of what the problem is.
Although tbh, until I read this thread, I didn't understand it properly. (Is that something I should admit??) So thanks people.
Bev.
-
Bev Nicolson -
Chris Green -
Laurie Brown -
Mark Rogers -
mick