An advisory (link: https://www.openssl.org/news/secadv_20140407.txt ) has been released concerning an implementation bug in several versions of the widely used OpenSSL software.
"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. Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including 1.0.1f and 1.0.2-beta1."
The advisory states that 1.0.1 users can resolve the issue by upgrading to 1.0.1g or recompiling using the -DOPENSSL_NO_HEARTBEATS switch. Users of 1.0.2 will need to wait for the next beta release to get this closed.
This website (link: http://heartbleed.com/ ) has been created to spread accurate details of the bug, which was determined to have been seen in releases of OpenSSL dating back to December 2011. Many websites and services are affected, including Mojang's decision to completely shut down the account authentication servers for Minecraft while the patch is being put in place.
Related Stories
After reporting the problems with OpenSSL, which has been nicknamed 'HeartBleed', 2 contributors have forward articles on why you should change your passwords.
Heartbleed, and why you should change your password
I always believed Mojang would keep my details safe, now I realise they are not in control of their own data. Mojang/Minecraft passwords should be changed immediately
Heartbleed Bug: Change All Your Passwords
The fallout from the Heartbleed bug is hitting the mainstream. The BBC has an article headlined "Public urged to reset all passwords".
Bruce Schneier calls it "catastrophic", giving this advice to sysadmins: "After you patch your systems, you have to get a new public/private key pair, update your SSL certificate, and then change every password that could potentially be affected." He also links to a webpage that will let you test servers for the bug, and an article on Ars Technica discussing the bug.
Ars Technica reports that four weeks after its disclosure huge swaths of the Internet remain vulnerable to Heartbleed. The article suggests that over 300,000 servers remain vulnerable.
What steps have you taken to protect yourself from this bug? What browser addons have you installed? Have you checked/updated the firmware on your home router? If you work in IT, what has the reaction been? Has your site been compromised? Has vulnerable code been updated, new keys genned, new certificates obtained, and old ones revoked?
Since the OpenSSL library is now undergoing a security review and a fork of it is underway as LibreSSL, it is possible that other vulnerabilities will be discovered. Then what? How likely is it that we will need to repeat this cleanup effort?
(more after the break)
(Score: 5, Informative) by NCommander on Tuesday April 08 2014, @06:00PM
The patch was dropped into the precise-security repos and have been applied to all machines related to SN. We're going to be replacing the SSL certificates as soon as we can get them reissued as a matter due diligence.
Still always moving
(Score: 0) by Anonymous Coward on Tuesday April 08 2014, @09:00PM
Thank you.
(Score: 0) by Anonymous Coward on Tuesday April 08 2014, @11:56PM
Have you, or are you considering implementing Perfect Forward Secrecy?
https://en.wikipedia.org/wiki/Perfect_forward_secr ecy [wikipedia.org]
(Score: 2) by The Mighty Buzzard on Wednesday April 09 2014, @12:56AM
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Wednesday April 09 2014, @02:30PM
Ok, this is just absolutely VERY cool. I've been playing with that add-on by checking various secure websites and it is shocking just who is using great settings/configs and who is using less great ones. my.yahoo.com scores well (88%), while Amazon scores poorly (23%). But worse, some banking sites score even lower. Likely not the end of the world, but it does seem to be time to start writing some emails to security groups. :)
(Score: 2) by The Mighty Buzzard on Wednesday April 09 2014, @12:51AM
My rights don't end where your fear begins.
(Score: 3, Informative) by The Mighty Buzzard on Tuesday April 08 2014, @06:05PM
My rights don't end where your fear begins.
(Score: 2) by The Mighty Buzzard on Tuesday April 08 2014, @06:36PM
Forgot to mention, this is assuming you went through all the other steps at heartbleed.com. Wouldn't be a bad time to look at stronger encryption certs either.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Wednesday April 09 2014, @01:25PM
there is hardly any Linux distribution that had not pushed the patched version very quickly, so whats special about Arch here?
(Score: 2) by The Mighty Buzzard on Wednesday April 09 2014, @07:05PM
My rights don't end where your fear begins.
(Score: 4, Informative) by Anonymous Coward on Tuesday April 08 2014, @06:11PM
If you're curious about your version of openssl and whether it's affected, just run:
openssl version
(Score: 5, Informative) by Bob The Cowboy on Tuesday April 08 2014, @06:33PM
And for the sake of completeness, here's what to check it against (from TFA):
(Score: 4, Informative) by VLM on Tuesday April 08 2014, @08:06PM
There are some complications, for example the patched Debian wheezy package reports
OpenSSL 1.0.1e 11 Feb 2013
However if the output of
zcat /usr/share/doc/openssl/changelog.Debian.gz | head -1
Looks like
openssl (1.0.1e-2+deb7u6) wheezy-security; urgency=high
its all good
or its +deb7u5 instead of u6 its also good
or otherwise reading the contents of /usr/share/doc/openssl/changelog.Debian.gz finds commentary on CVE-2014-0160 having been patched, then you're all good.
The level of panic you need to express of course depends dramatically on what the specific machine does with SSL.
(Score: 1) by JackZ on Wednesday April 09 2014, @06:29PM
I was running a vulnerable 0.9.8. I had installed mod-spdy-beta and it included a patched (and vulnerable) ssl. I updated spdy and my old lucid server is no longer vulnerable. I did not have spdy enabled, just installed.
(Score: 4, Insightful) by MrGuy on Tuesday April 08 2014, @06:20PM
So, apparently we know which release the bug was introduced in.
What I want to know is who committed the change that created the bug, and who that person works for.
Major security bugs happen all the time without deliberate malicious intent. But at this point, I'm not willing to believe any changes that could, if exploited, allow a huge amount of encrypted traffic to be read by a third party to be "just mistakes." Just as we wait for explicit proof to rule out terrorism in major industrial or transportation accidents these days, I'd like explicit proof to rule out "deliberate weakening of security by government forces" before I believe this was an innocent error.
I might be paranoid, but am I paranoid ENOUGH?
(Score: 3, Interesting) by VLM on Tuesday April 08 2014, @08:36PM
Why am I doing this for you guys, when it doesn't seem too hard... I'm looking at PR 2658 last day of 2011
I'd be VERY careful about verification before boiling the tar, grabbing the pitchforks, and gathering feathers. To me it looks like an honest mistake.
Neither Dr H. nor the pull request submitter Professor S. from the university in .de land look like typical NSA plants.
I hesitate to provide more info for whats likely a witch hunt but I'd find it interesting to know if other witch hunters are none the less on the same trail.
That line in ssl/d1_both.c and code first added in the PR above, /* Read type and payload length first */
Yeah, I think you needed to check that bit.
(Score: 4, Interesting) by combatserver on Tuesday April 08 2014, @09:54PM
Perhaps.
From Dr. Steve Henson's Home Page:
"PKCS#8 and PKCS#5 code.
I added code to handle PKCS#8 format private keys. This supports both the old PBE1 standards of PKCS#5 v1.5 and the newer PBE2 standards of PKCS#5 v2.0. The test vectors on RSA site were generated using my OpenSSL code.
We all know what happened over at RSA.
.
http://www.drh-consultancy.demon.co.uk/ [demon.co.uk]
.
Robin Seggelmann's Home Page:
"thesis
SCTP - Strategies to Secure End-to-End Communication
R. Seggelmann
Ph.D. Thesis, University of Duisburg-Essen
October 2012"
.
http://www.robin-seggelmann.de/ [robin-seggelmann.de]
From the Wikipedia Entry for SCTP:
"SCTP is sometimes a good fingerprinting candidate. Some operating systems ship with SCTP support enabled, and, as it is not as well known as TCP or UDP, it is sometimes overlooked in firewall and intrusion detection configurations, thus often permitting probing traffic."
.
Come to your own conclusions...
I hope I can change this later...
(Score: 2) by omoc on Wednesday April 09 2014, @01:16PM
Here is the commit that introduced the vulnerability:
http://git.openssl.org/gitweb/?p=openssl.git;a=com mit;h=4817504d069b4c5082161b02a22116ad75f822b1 [openssl.org]
(Score: 5, Informative) by iroll on Tuesday April 08 2014, @06:39PM
If you use OSX, it sounds like the official version is still safe (0.9.8), but many readers of this website have probably installed vulnerable versions with Fink or MacPorts (I know I did!). Make sure you upgrade!
(Score: 2) by Sir Finkus on Tuesday April 08 2014, @10:28PM
Thanks a lot, I hadn't even thought of that.
Join our Folding@Home team! [stanford.edu]
(Score: -1, Troll) by Anonymous Coward on Wednesday April 09 2014, @07:47AM
OSX, power users? LOL
(Score: 2, Interesting) by Anonymous Coward on Tuesday April 08 2014, @06:58PM
I've read that openSSH uses openSSL. Does this mean that Linux boxes that exposes an SSH port to the public internet are also vulnerable to Heartbleed? Any info would be appreciated.
(Score: 2, Informative) by GeminiDomino on Tuesday April 08 2014, @07:01PM
OpenSSH doesn't use the openSSL library. A bug in core crypto will generally hit both, but in this case, your openSSH should be just fine.
"We've been attacked by the intelligent, educated segment of our culture"
(Score: 2) by MrGuy on Tuesday April 08 2014, @07:30PM
Buh? OpenSSH doesn't use the OpenSSL library? Since when?
Last time I checked, OpenSSH wouldn't run without OpenSSL.
(Score: 4, Informative) by GeminiDomino on Tuesday April 08 2014, @08:33PM
OpenSSH uses some OpenSSL functions for key generation. Heartbleed is a flaw in the TLS implementation, which doesn't come into play.
"We've been attacked by the intelligent, educated segment of our culture"
(Score: 2) by The Mighty Buzzard on Tuesday April 08 2014, @08:40PM
My rights don't end where your fear begins.
(Score: 3, Funny) by FuckBeta on Tuesday April 08 2014, @07:18PM
So, Fuck Beta!
Quit Slashdot...because Fuck Beta!
(Score: 1) by cykros on Wednesday April 09 2014, @01:23AM
Man, I'm glad I finally put two and two together with this vulnerability, because it was really starting to get weird when just about every site I went to today had Certificate Patrol (the firefox extension) popping up warnings about a new unexpected certificate.
And I'm mostly just posting this here in case anyone else goes into a mini-panic about the possibility of an ongoing mitm attack like I did. Don't worry; the web just collectively all changed SSL certs on the same day.
(Score: 2) by egcagrac0 on Wednesday April 09 2014, @06:29AM
I wonder what new vectors stem from that?
(Score: 2, Informative) by egp on Wednesday April 09 2014, @02:06AM
Check the status of any web site at http://filippo.io/Heartbleed/ [filippo.io]
(Score: 1) by tomtomtom on Wednesday April 09 2014, @09:17AM
Given potentially username/passwords transmitted over TLS secured connections were also compromised via this bug, I'm surprised more sites haven't been enforcing a change of password at next login following this issue. Is it just because the effort/pain involved would be immense?
(Score: 2, Interesting) by egp on Wednesday April 09 2014, @01:03PM
xkcd [xkcd.com]
(Score: 1) by marcolinux on Thursday April 10 2014, @02:19PM
Be sure to checkout the explain: http://www.explainxkcd.com/wiki/index.php/1353 [explainxkcd.com]
Good explanation of citation from the Tears in rain soliloquy.
Voynich script is openSource. Ultrasound, can see u "exercise".