CVE-2014-0160: Heartbleed Bug: OpenSSL Vulnerability
 

See http://heartbleed.com/ for complete information and recommendations:
OpenSSL 1.0.1g is the upgrade that fixes the bug.

Hope this helps some.

yup. good information to pass around. also good to see that companies like RedHat have already stepped up and not only fixed the bad code but removed several of the older encryption models to increase security.

https://securityblog.redhat.com/tag/tls/

in fact RedHat fixed it back in Dec of 2013.

US-CERT Alert (TA14-098A) OpenSSL 'Heartbleed' vulnerability (CVE-2014-0160)
 

US-CERT published OpenSSL 'Heartbleed' vulnerability (CVE-2014-0160) (see https://www.us-cert.gov/ncas/alerts/TA14-098A), dated 04/08/2014 08:46 AM EDT.

The US-CERT Notice includes the following:
Essentially, don't doddle, get on the stick, do it now.

Hope this helps some.

Slackware users: Slackware released upgraded packages for release versions 14.0, 14.1 and Current 04/08/2014 (prior releases are not affected).

I'm a little unclear on something, This issue only affects SSH keys, and NOT a site's SSL Certificate(s)?
Sorry if that's lame, but there's way too much "new" data for me to process my question atm.

I hope I don't have to re-key a hundred+ servers.

Thanks.

Perhaps a look-see at https://www.schneier.com/ and an article he recommends as a worthwhile read, http://arstechnica.com/security/2014...oulette-style/ and http://www.openssl.org/docs/HOWTO/keys.txt as well as http://www.openssl.org/docs/HOWTO/certificates.txt.

Both the certificate and keys documents are found in doc/HOWTO in an installed OpenSSL.

Hope this helps some.

Thanks! Reading up now...

Edit:
Mass scanner

Usage: fill up a scan.txt file with target IPs or hosts and run
any vulnerable hosts will have an ip.txt in the directory it was run from.

I don't see evidence of that in the link you posted.

the issue presents itself when a tls layer (aka ssl/tls library) is hooked into the listening port and a socket is made for the connection. the issue around certs is rather basic. server side has the private key which is used in the asymmetric process for securely exchanging the dynamic symmetric keys used to secure the communications. if the private key is exposed then the cert is now compromised and so are any additional data streams built using that cert. the PFS option helps but is not always used. but even having the private key does not mean the public at large can "see" anything, the hacker would need to be able to collect unicast data streams that are far away, etc, which is not so trivial.

the crux of the issue is, this tls issue exposes data from RAM, which could be parts of the unencrypted data from a TLS stream, which is a bad thing. the pita part is, after patching, new certs need to be generated using a new private key. some devices build an initial local CA during install time used for self-signing, this can be a pita to gen a new local CA and then redo the self-signed certs, and it gets more of a pita depending on if/how these self-signed certs were deployed, etc.

wow, some new "heartbeat" feature turned out to be not so good. in this day & age it baffles me why functions like this are not fuzz'd beyond the dead horse before being released.

well, on a cheery note, happy fixin.

this is a good read.

http://article.gmane.org/gmane.os.openbsd.misc/211963

a blatant disregard for memory management? how so, this is a sensitive library used to ensure privacy, surely it was reviewed a zillion times before being compiled, and the fuzz'd for added assurance?,...... makes you wonder why it was done wrong, and why it took until now to catch.

if i am not mistaken, only the memory address space used by the process handling the tls library can be leaked. i do not believe its any random parts of all memory, but please correct me on this if need be........

What do you think would be the best approach to fix this issue for users (particularly lesser experienced users) of EOL distros, such as Fedora 18? I don't think there will be any sort of fix pushed since those distros are EOL.

Thanks.

This caused quite a panic, with CloudControl sending out press releases to its customers as early as yesterday.

SSH and SSL are two different projects. OpenSSH is unaffected.

Yes, I got that "now" after much research in these last few days. Thanks!

Still a good time to review and update Security practices for remotely managed hosts.

install new openSSL package (just because its not in a repository for the specific distro that doesnt mean you are stuck), or recompile with the heartbeat option disabled.

installing "new" doesnt mean you need to go "up" in version, you can also downgrade to get away from the heartbeat option, etc. one needs to ask themselves, other than security related fixes (which not every new version has), why are you upgrading the package? many time new versions have additional features, and in this case the new feature was, well, [fill in your words here].

Maybe it's time for a fork ...