Heartbleed

[cadandcookies]

In case you haven't heard, now is a really good time to go and change your passwords.

This article (http://techcrunch.com/2014/04/07/massive-security-bug-in-openssl-could-effect-a-huge-chunk-of-the-internet/) explains it better than I can-- maybe some of the network gurus around here have more details?

I didn't see a thread about it anywhere and figured it's probably relevant to a lot of the users here.

[plnyyanks]

maybe some of the network gurus around here have more details?

This specific exploit is actually not quite network related. It's more of a programming oversight (with huge implications). Basically, there's a part of the SSL protocol called the heartbeat, which allows for a connection to remain open over time - the client sends a little message to the server saying, "hey! don't kill my connection" and the server acknowledges it and sends some data back.

The way the protocol is defined, the client sends its packet of data and a number representing the size of that data as validation (something pretty common to do). However, openSSL doesn't check that the given size actually corresponds to the actual size of the payload - it just allocates a chuck of memory that sized and returns it. This means that if the user tells openSSL that the payload is bigger that it is, the server will actually dump a portion of its memory back (which can include things like private keys, passwords, etc.).

You can check the vulnerable code out here (https://github.com/openssl/openssl/commit/bd6941cfaa31ee8a3f8661cb98227a5cbcc0f9f3#diff-38dc72994741420e2b6c5ee074941a45), and you can see it just does a memcpy and if you look at the surrounding code, those bounds aren't checked.

/* Allocate memory for the response, size is 1 byte
* message type, plus 2 bytes payload length, plus
* payload, plus padding
*/
buffer = OPENSSL_malloc(1 + 2 + payload + padding);
bp = buffer;
/* Enter response type, length and copy payload */
*bp++ = TLS1_HB_RESPONSE;
s2n(payload, bp);
memcpy(bp, pl, payload);

Although the situation is different, the moral of the story remains the same...
http://imgs.xkcd.com/comics/compiler_complaint.png

[cgmv123]

http://imgs.xkcd.com/comics/heartbleed_explanation.png

[MCMechTech]

You will want to be sure your web server has been updated to address the vulnerability before you change your passwords. Otherwise you could make the problem worse by exposing both the old and new password to an attack.

[cadandcookies]

You will want to be sure your web server has been updated to address the vulnerability before you change your passwords. Otherwise you could make the problem worse by exposing both the old and new password to an attack.

We had a security expert come in to my AP Computer Science class who recommended changing all passwords now, and then again in 3-4 weeks. The rationale being that some will have fixed it ASAP, but some will only get around to it later (or something along those lines).

[Lucario]

We had a security expert come in to my AP Computer Science class who recommended changing all passwords now, and then again in 3-4 weeks. The rationale being that some will have fixed it ASAP, but some will only get around to it later (or something along those lines).

https://lastpass.com/heartbleed/ actually has a web tool to check if the server's been patched. You can use this to check to see if its time to change your password.

Also, if you're a web-admin, you'll want to check your own site's SSL if you're doing anything sensitive- both the patch and a re-key has to be applied for you to be protected.

[rich2202]

This specific exploit is actually not quite network related.


Now it is:

Cisco and Juniper, two of the largest router and Internet equipment makers, said today that the vulnerability, which exposes encrypted data like passwords, is present in their routers, switches and firewalls.

http://www.komando.com/blog/247808/the-heartbleed-bug-just-got-very-very-worse

[Lucario]

Now it is:

Yep. Also, in Heartbleed-vulnerable routers, since almost all routers also act as a web server, SSL connections between it and clients (such as router management clients) are vulnerable to MITM (Man-In-The-Middle) attacks and decryption.

[Chris_Ely]

Anyone know if CD is affected? The tool that Alan linked to is inconclusive.
Unable to get HTTP headers for www.chiefdelphi.com
Site: www.chiefdelphi.com
Server software: Not reported
Was vulnerable: Possibly (might use OpenSSL, but we can't tell)
SSL Certificate: Unable to extract SSL information for that host

[Pat Fairbank]

Anyone know if CD is affected? The tool that Alan linked to is inconclusive.
Nope -- CD doesn't use SSL/HTTPS. Port 443 on chiefdelphi.com is blocked.

[Joe Ross]

Nope -- CD doesn't use SSL/HTTPS. Port 443 on chiefdelphi.com is blocked.


In other words, don't use an important password here.

[alex.lew]

In other words, don't use an important password here.
Is there any password that could be more important?