CVE-2014-0160: Heartbleed Bug: OpenSSL Vulnerability

mattydee · 04-15-2014, 01:22 PM

Thanks. I'm not sure I understand that code, so I'll have to read up on network analysis 101.

In a purely abstract sense though, wouldn't we have to have a way to detect client packets that declare length of x to be greater than actual length of x, where x is whatever keep alive data that is responsible for the heartbeat?

Stella456 · 04-20-2014, 06:16 AM

Quote:

Originally Posted by wh33t

Code:

root@wh33t:~# dpkg -s openssl
Package: openssl
Status: install ok installed
Priority: optional
Section: utils
Installed-Size: 901
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Architecture: amd64
Version: 1.0.1-4ubuntu5.12
Depends: libc6 (>= 2.15), libssl1.0.0 (>= 1.0.1)
Suggests: ca-certificates
Conffiles:
 /etc/ssl/openssl.cnf ce31ab5015842bf7c2939514a634e0e4
Description: Secure Socket Layer (SSL) binary and related cryptographic tools
 This package contains the openssl binary and related tools.
 .
 It is part of the OpenSSL implementation of SSL.
 .
 You need it to perform certain cryptographic actions like:
  -  Creation of RSA, DH and DSA key parameters;
  -  Creation of X.509 certificates, CSRs and CRLs;
  -  Calculation of message digests;
  -  Encryption and decryption with ciphers;
  -  SSL/TLS client and server tests;
  -  Handling of S/MIME signed or encrypted mail.
Original-Maintainer: Debian OpenSSL Team <pkg-openssl-devel@lists.alioth.debian.org>

Hi. I was checking this out the other day. If you type:

openssl version

into the terminal (that's in normal terminal, not root). It will tell you which version you have, which I have found tends to be the non-updated one. BUT - if you type

openssl version -b

It will tell you the date it was fixed. So although your version might not have been replaced with the 'g' version it has been patched. If the date is 7 April or after, it is safe.

I have tried this on both debian and xubuntu. Debian upgraded to 'f' so still the vulnerable version, but showed latest update fix as 14 April. Xubuntu still shows the old version with a fix date of 7 April.

My question now is - do I need to change my password on this site?!!! Apart from checking out my 'buntu' distros I have changed passwords on sites supposed to be affected - ie google/gmail, godaddy and various others. I now have so many new passwords I need a special notebook! So would be grateful if someone could let me/us known - is this site affected? If not, no need to change passwords. If it did use openssl, has it been patched so we need to change passwords after patch date. Thanks!

Stella456 · 04-20-2014, 08:55 AM

And a thought - I'm a great one for conspiracy theories! So - the openssl problem affected just about everyone (including Google and Linux) except Microsoft and the banks - hmm!

Smokey_justme · 04-20-2014, 09:25 AM

Hmm, Google wasn't affected (from what I know)... And some banks we're affected...

Now, regarding the changing password from this site.. This forum doesn't use SSL for logins.. That means your password is always unsecure here and should not be the same as one used in you e-mail account or bank password

Stella456 · 04-20-2014, 09:45 AM

Cheers! I have a different password on here. No need to change it then! I read a list, somewhere, that those affected included GMail and Google, plus Facebook. Anyway, one less password to change!

tronayne · 04-20-2014, 10:02 AM

Pretty much the only sites you need to worry about at the https sites (not http).

You can use http://filippo.io/Heartbleed or https://lastpass.com/heartbleed to test whether a site may be vulnerable (that may is important) and you, again, may get different answers from each. The first reports

Quote:

All good, linuxquestions.org seems fixed or unaffected!

the second reports

Quote:

Site: linuxquestions.org
Server software: nginx
Was vulnerable: Possibly (known use OpenSSL, but might be using a safe version)
SSL Certificate: Possibly Unsafe (created 2 years ago at Jun 23 19:25:28 2012 GMT) Additional checks SSL certificate history checks yielded no new information
Assessment: It's not clear if it was vulnerable so wait for the company to say something publicly, if you used the same password on any other sites, update it now.

Hm.

As noted by @Smokey_justme above, LinuxQuestions.org doesn't use SSL for log in.

Basically, you need to update your system(s) to openssl-1.0.1g (or higher) and, if your distribution uses openssl-solibs-1.0.1g (or higher), too. You need to reboot after applying the update and you need to revoke and regenerate your public/private SSL keys and certificates (if any). This is CYA stuff.

This has nothing to do with SSH, you don't need to worry about that (yet?).

For secure sites you use (banks, credit card issuers, etc.), you'll want to check the site with one or both of the tools listed above and decide for yourself about changing the passwords on those sites.

And, what the heck, you ought to periodically change passwords in any event, eh?

Hope this helps some.

Linux_Kidd · 04-21-2014, 03:13 PM

Quote:

Originally Posted by metaschima

Here's a detailed explanation of the bug:
http://www.theregister.co.uk/2014/04...eed_explained/
http://git.openssl.org/gitweb/?p=ope...58c4899d#l3969

The main issue seems to be this memcpy:

Code:

memcpy(bp, pl, payload);

The 'payload' variable is sent by the attacker. I don't see why it is even used here, when the correct length of the received data was also used and submitted in the same commit 's->s3->rrec.length' but in a different place. The correct calculation for bounds checking was also used in the commit, but in a different place '1 + 2 + payload + padding'.

Of course, there's no way to prove it was or was not deliberate, but I'm starting to lean away from accidental.

EDIT:
I think I'll start looking through code submitted on major holidays like Christmas and New Years, and maybe they should lock down git on these days.

hmmm, most big orgs have change freezes around times like this. no patching, no new software, etc etc. when i worked at MBUSA they had a strict small yearly window to get things done in the environment, after that it was locked to anything new (less patches and what not, but very very tight on changes, etc). there should be a ISO that defines the dates when new code cannot be released, etc.

Quote:

Originally Posted by tronayne

Pretty much the only sites you need to worry about at the https sites (not http).

not really.... anything that loads the problem libraries under a listening port is a problem, not just HTTP+SSL, etc.