[SOLVED] Heartbleed

moisespedro · 04-08-2014, 10:45 AM

Quote:

Originally Posted by ruario

Worked for me. Try this sequence:

Code:

$ cd /tmp
$ wget -R "openssl-1.0.1f.*" -nH --cut-dirs=3 -rl2 ftp://mirrors1.kernel.org/slackware/slackware-14.1/patches/source/openssl/
$ wget -P source/openssl https://www.openssl.org/source/openssl-1.0.1g.tar.gz
$ su -
# cd /tmp/source/openssl
# bash openssl.SlackBuild

metageek told me exactly the same thing, I was picking the slackbuild folder from source and not patches. It doesn't work.

EDIT: And by the way I learnt new things with your command thanks

http://explainshell.com/explain?cmd=...e%2Fopenssl%2F

ruario · 04-08-2014, 10:56 AM

Quote:

Originally Posted by moisespedro

metageek told me exactly the same thing, I was picking the slackbuild folder from source and not patches. It doesn't work.

Ok, cool. Glad you got there, even if I was a little slow!

Quote:

Originally Posted by moisespedro

EDIT: And by the way I learnt new things with your command thanks

Well at least I was of some use!

As you can see I could have cut another directory but I wasn't sure (and didn't check) if the SlackBuild also creates a folder in /tmp called "openssl" during the build and packaging process. Just in case I decided not to cut the parent ("source") directory.

EDIT: I also didn't really need to explicitly set the recursion level to 2, since that is all there was in this case but it is a force of habit, having occasionally grabbed way too much in the past.

moisespedro · 04-08-2014, 11:09 AM

Well, lets say that the current usage of wget for me doesn't get past "wget -c" :P but I am learning

Alien Bob · 04-08-2014, 11:13 AM

From http://slackware.osuosl.org/slackwar.../ChangeLog.txt

Code:

Tue Apr  8 14:19:51 UTC 2014
a/openssl-solibs-1.0.1g-x86_64-1.txz:  Upgraded.
n/openssl-1.0.1g-x86_64-1.txz:  Upgraded.
  This update fixes two security issues:
  A missing bounds check in the handling of the TLS heartbeat extension
  can be used to reveal up to 64k of memory to a connected client or server.
  Thanks for Neel Mehta of Google Security for discovering this bug and to
  Adam Langley <agl@chromium.org> and Bodo Moeller <bmoeller@acm.org> for
  preparing the fix.
  Fix for the attack described in the paper "Recovering OpenSSL
  ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack"
  by Yuval Yarom and Naomi Benger. Details can be obtained from:
  http://eprint.iacr.org/2014/140
  For more information, see:
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0076
  (* Security fix *)

From http://slackware.osuosl.org/slackwar.../ChangeLog.txt

Code:

Tue Apr  8 14:19:51 UTC 2014
patches/packages/openssl-1.0.1g-x86_64-1_slack14.1.txz:  Upgraded.
  This update fixes two security issues:
  A missing bounds check in the handling of the TLS heartbeat extension
  can be used to reveal up to 64k of memory to a connected client or server.
  Thanks for Neel Mehta of Google Security for discovering this bug and to
  Adam Langley <agl@chromium.org> and Bodo Moeller <bmoeller@acm.org> for
  preparing the fix.
  Fix for the attack described in the paper "Recovering OpenSSL
  ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack"
  by Yuval Yarom and Naomi Benger. Details can be obtained from:
  http://eprint.iacr.org/2014/140
  For more information, see:
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0076
  (* Security fix *)
patches/packages/openssl-solibs-1.0.1g-x86_64-1_slack14.1.txz:  Upgraded.

And from http://slackware.osuosl.org/slackwar.../ChangeLog.txt

Code:

Tue Apr  8 14:19:51 UTC 2014
patches/packages/openssl-1.0.1g-x86_64-1_slack14.0.txz:  Upgraded.
  This update fixes two security issues:
  A missing bounds check in the handling of the TLS heartbeat extension
  can be used to reveal up to 64k of memory to a connected client or server.
  Thanks for Neel Mehta of Google Security for discovering this bug and to
  Adam Langley <agl@chromium.org> and Bodo Moeller <bmoeller@acm.org> for
  preparing the fix.
  Fix for the attack described in the paper "Recovering OpenSSL
  ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack"
  by Yuval Yarom and Naomi Benger. Details can be obtained from:
  http://eprint.iacr.org/2014/140
  For more information, see:
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0076
  (* Security fix *)
patches/packages/openssl-solibs-1.0.1g-x86_64-1_slack14.0.txz:  Upgraded.

Earlier versions of Slackware are not affected.

Eric

moisespedro · 04-08-2014, 11:19 AM

Did you do anything different other than using the same source directory and picking up the new tarball? Just to know if I can keep my package or if I should grab the official one.

Alien Bob · 04-08-2014, 11:29 AM

I did not create them. I only mention their availability.
And: use the official packages where possible is my advice.

Eric

moisespedro · 04-08-2014, 11:42 AM

I am gonna use the official ones then.

metageek · 04-08-2014, 04:19 PM

We now have official packages, which I also prefer myself. So I am going to reinstall them.

I'm marking this as resolved.

aaazen · 04-08-2014, 07:32 PM

Quote:

Originally Posted by metageek

...
right now I do not want to ssh into any server not yet patched... at least my client is already clean.

Now get all new passwords, ssl keys... what a nightmare!

As far as I can tell sshd does not use openssl.

Code:

#lsof -n |grep ssl

Here is the blurb from the OpenBSD patch:

Quote:

OpenBSD 5.4 errata 7, Apr 8, 2014: Missing bounds checking in OpenSSL's
implementation of the TLS/DTLS heartbeat extension (RFC6520) which, if
exploited, can result in a leak of memory contents.

After patching, private keys and certificates exposed to services running
this code (for example web/mail server SSL certificates) should be replaced
and old certificates revoked.

Only SSL/TLS services are affected. Software that uses libcrypto alone
is not affected. In particular, ssh/sshd are not affected and there
is no need to regenerate SSH host keys that have not otherwise been exposed.

dc_eros · 04-08-2014, 09:26 PM

Good thing I'm still at 13.37

moisespedro · 04-08-2014, 09:54 PM

Interesting discussion here http://www.reddit.com/r/linux/commen...e_openssl_how/

metageek · 04-08-2014, 11:03 PM

Quote:

Originally Posted by comet.berkeley

As far as I can tell sshd does not use openssl.

Code:

#lsof -n |grep ssl

Ok, this sounds a lot better

but I've still changed passwords, which is not a bad thing to do anyway.

tronayne · 04-09-2014, 09:43 AM

The US-CERT notice arrived in my mail this morning (see https://www.us-cert.gov/ncas/alerts/TA14-098A). It includes a couple of points that weren't (at least to me) quite so obvious in other alerts from yesterday:

Any keys generated with a vulnerable version of OpenSSL should be considered compromised and regenerated and deployed after the patch has been applied.
US-CERT recommends system administrators consider implementing Perfect Forward Secrecy http://en.wikipedia.org/wiki/Perfect_forward_secrecy to mitigate the damage that may be caused by future private key disclosures.

Reading the Perfect Forward Security article (darned interesting) led to a reference link, https://community.qualys.com/blogs/s...orward-secrecy, that I found truly interesting.

I also found that I'm not that up on just how to regenerate all keys necessary and that implementing Perfect Forward Security might be a little beyond my skill levels.

So, I'm wondering, if someone with more knowledge than I might wish to add information here (or elsewhere) discussing the steps to take to accomplish both of the recommended steps? Reading the manual is one thing, actually doing it might just be another.

[EDIT]
The documentation (on my systems in /usr/doc/openssl-1.0.1g/doc/HOWTO) has clear instructions on generating keys and on generating certificates.

I'm thinking that's probably good enough.
[/EDIT]

BenCollver · 04-09-2014, 01:48 PM

It looks as though OpenSSL didn't actually leak private keys.

http://blog.erratasec.com/2014/04/wh...ivate-key.html

lazardo · 04-09-2014, 01:48 PM

Quote:

What versions of the OpenSSL are affected?

Status of different versions:

OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
OpenSSL 1.0.1g is NOT vulnerable
OpenSSL 1.0.0 branch is NOT vulnerable
OpenSSL 0.9.8 branch is NOT vulnerable

Bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. OpenSSL 1.0.1g released on 7th of April 2014 fixes the bug.

http://heartbleed.com/
http://blog.existentialize.com/diagn...bleed-bug.html