Note to anyone who uses SSL and these versions... it's a must read and should be patched immediately. Looks like a really messy fallout due to one small coding error.

I don't like the look of this bug.

Report are coming in already of potential problems.

Report: Heartbleed Bug Exposes Yahoo User Passwords [webmasterworld.com]

Very nasty, and much much worse than the GNUTLS or Apple bugs because OpenSSL is much more widely used in security critical, especially server, software.

It is possible for encryption keys to be leaked, so you may even need new certificates.... as well as new passwords. Anything that could have been in your servers memory during an SSL session using a vulnerable version of OpenSSL.

I have occasionally cursed CPanel for being so far behind on OpenSSL (0.9.8e from 2007 which, I believe, still doesn't allow SNI). But... here's a good case in favor. Only relatively new versions are affected by this (releases since 19 April 2012).

Since most people on shared hosting or reseller accounts are likely on CPanel-driven servers, they should be okay.

Here's a web page that'll check your server on port 443 for the vulnerability, and will return a small chunk of memory contents when the vulnerability is there:
[filippo.io...]

It does affect other services using openssl though, but not openssh from what I gather.

A sequence of two articles from ArsTechnica present a sobering overview of the extent of situation....

Critical crypto bug in OpenSSL opens two-thirds of the Web to eavesdropping
Exploits allow attackers to obtain private keys used to decrypt sensitive data.
by Dan Goodin - Apr 7 2014, 5:10pm PST
[arstechnica.com...]

The second goes into the steps of the recovery process...

Critical crypto bug exposes Yahoo Mail, other passwords Russian roulette-style
OpenSSL defect still exposing sensitive data even after patch is released.
by Dan Goodin - Apr 8 2014, 11:01am PST
[arstechnica.com...]

All of this means that applying the OpenSSL patch is only the starting point on the multi-step path of Heartbleed recovery. Website operators should strongly consider replacing their X.509 certificates after applying the update and getting all users and administrators to change passwords as well. While it's possible that none of this data has been compromised, there's no way to rule it out, either.

It's probably premature for users to replace passwords across the board, but for sites they know have received the OpenSSL patch, it may be a good idea to change login credentials. People who are truly security conscious may want to change passwords a second time if they notice a patched site later updates its digital certificate....

I don't know about Linux but, in the BSD world, it was not a factor unless you used the newest release and, even then, the fix was easy and it only took us a minute to self patch it.

It might not be a factor for anyone since it's not known if anyone but Google discovered it but it also doesn't leave any trails.

It might not be a factor for anyone since it's not known if anyone but Google discovered it...

I've compared notes with several friends, and we've all been getting a huge amount of email spam. I started noticing it early this am. Have also seen a couple of hacked emails that shouldn't fool anyone, but some folks will click on anything.

This vulnerability note contains a list of identified vendors....

Vulnerability Note VU#720951
OpenSSL heartbeat information disclosure
Original Release date: 07 Apr 2014 | Last revised: 08 Apr 2014
http://www.kb.cert.org/vuls/id/720951 [kb.cert.org]

I note that several BSD projects are on the list. What makes it more sinister, IMO, is that it doesn't leave any trails.

I am wondering whether this security breach might affect IIS, or whether that world uses different security suppliers.

I note that several BSD projects are on the list.

They are on the list because they use openssl for some things in the base. However, it only applies to the most recent new release in FreeBSD version 10 which not everyone has started using yet. Version 8 and 9 aren't affected as they use older versions of openssl that weren't affected. And if they installed their own version of openssl from ports, and kept it updated as most do, then they have already been unaffected by this problem long before today.

In any case, the fix on FreeBSD was a one line change to the Makefile and recompiling. A source and binary patch was released sometime this afternoon and is installed doing a simple update.

I used this set of commands for some versions of Ubuntu that are at end of life (13.04), as the repo's do not have a patch.

^{cd /tmp
wget [openssl.org...]
tar xzvf openssl-1.0.1g.tar.gz
cd openssl-1.0.1g && sudo ./config && sudo make && sudo make install
ln -sf /usr/local/ssl/bin/openssl `which openssl`}

So I didn't get an email from any service I use about resetting my passwords. Should that be done?

There's not an easy answer.

If a site never had the vulnerability, you're likely fine, though knowing if they did or not isn't exactly public info.

If a site had the vulnerability but wasn't victim to a successful attack that gave up its own credentials or yours.... then you're fine. But it's hard to tell whether it's the case.

If a site had the vulnerability and gave up credentials, then they have a lot of work to do to audit their system and ensure no one has unauthorised access. You'd want to reset your password but would want to wait until you have the all clear to.

The issue with resetting your password just now, is that you'll be putting your credentials into memory using their password reset functionality and likely increasing the chances of them being seen.

The probabilities are likely tiny, but... :o)

rustybrick, maybe they got caught in spam?

I've never received this many explanatory emails from websites I have used recently about this vulnerability. Just incredible.

Yea, I am surprised. Maybe they will send them out in a couple days? The risk is very limited but who knows if a hacker got in and if/when they may use those passwords.

I have gotten only one email so far from services I use.

If a site had the vulnerability but wasn't victim to a successful attack

Let's get something straight here.

1) There are no known attacks of any kind whatsoever anywhere in the world.

2) Even if there was, no one would know it cause it doesn't leave any traces.

3) This vulnerability was discovered by Google engineers and others and not by any bad things happening. Whether anyone else even knew this thing existed is unknown and unpublished.

So let's not get so excited. I fixed my servers within a couple of hours of finding out about this. I would think most of the big boys would be able to do the same thing.

Your self-assuredness is amusing. I'm not sure what you're setting straight other than you've patched your servers and we don't know the extent of any damage caused.

I would safely put money on this exploit having been used in the last 2 years, and FWIW the heartbeats can be logged but clearly by default, in most cases, it wouldn't be.

Another amusing thing, an arstechnica article about this vulnerability had people apparently stealing each others passwords in the comments section, they hadn't patched it in time.

As I see it we can define two periods in which the vulnerability might have had effect. The first period is between March 14 2012 and April 7 2014. In this period the bug was present in updated OpenSSL versions and could have been used if anyone knew of the existence.

The second period is between April 7 and the moment where each individual server owner updated their OpenSSL to version 1.0.1g or removed the heartbeat functionality from their vulnerable OpenSSL version by recompiling the source.

If anyone has been affected by the hack in the first period is unknown, and will likely be unknown in the future because heartbeat packets are normally not logged by servers. Personally I am willing to assume that the vulnerability has not been used in that period because nobody with bad intentions knew the existence. But that is an assumption partly based on wishful thinking and not a hard fact.

But you can be sure that servers have been attacked in the second period, starting minutes after the bug was published. There are public records of Alexa top 1000 sites vulnerable to the bug in the first 24 hours, including Yahoo, Stackoverflow, DuckDuckGo and Flickr. If script kiddies were able to check these sites within minutes after the publication, be assured that professional hackers did the same, but with more dedication and computing resources to download as much information as possible in the short time they had before the security staff of those sites started to fix the bug in their systems.

So, even it the risk for small site owners who upgraded their OpenSSL soon after the announcement is small simply because they weren't on the radar of hackers in that small period of time the vulnerability could have been exploited, large amounts of data exist now in the hands of hackers who only have to organize this data to find all kind of security related data like usernames, passwords and public and private parts of security certificates.

And I don't even want to speculate about the consequences if one of the certification authorities has been vulnerable and attacked, because that would set the whole trust tree of security through certificates at risk.

One final word for drhowarddrfine saying:

And if they installed their own version of openssl from ports, and kept it updated as most do, then they have already been unaffected by this problem long before today.

That is where the problem is. Those servers which were updated constantly with the newest software were the ones which were vulnerable the last two years. Lazy administrators who didn't update their OpenSSL for years are the ones who had a better protected system than their active colleagues. Sad but true.

I had my servers patched yesterday, however what concerns me is this is going to have any impact on customer trust, and online shopping.

Hopefully people will have short attention spans, and once the story is out of the news, it will be long forgotten.

I also wonder if the NSA knew about this bug for years, and was exploiting it. Now where did I put my tinfoil hat :)

The Heartbleed Hit List: The Passwords You Need to Change Right Now [mashable.com]

That lists some major service providers and their statements regarding the issue. The general advice from providers who has used openssl is that passwords should be reset "just in case".

Posted by Cloudflare earlier today, April 11, 2014...
https://www.cloudflarechallenge.com/heartbleed [cloudflarechallenge.com]

The Heartbleed Challenge
Can you steal the keys from this server?
Has the challenge been solved yet? YES

So far, two people have independently solved the Heartbleed Challenge.

The first was submitted at 4:22:01PST by Fedor Indutny (@indutny). He sent at least 2.5 million requests over the span of the challenge, this was approximately 30% of all the requests we saw. The second was submitted at 5:12:19PST by Ilkka Mattila of NCSC-FI using around 100 thousand requests.

We confirmed that both of these individuals have the private key and that it was obtained through Heartbleed exploits. We rebooted the server at 3:08PST, which may have contributed to the key being available in memory, but we can’t be certain....

Note for those trying to connect to the Heartbeat Challenge page above... if your browser is set up properly, it will not connect you to the page via the link above. On FF, I get this message...

Secure Connection Failed

An error occurred during a connection to www.cloudflarechallenge.com.

Peer's Certificate has been revoked.

(Error code: sec_error_revoked_certificate)...

Elsewhere on the CloudFlare site (on cloudflare.com), there's a confirmation that four individuals in all obtained the private key for the test site, using only the Heartbleed exploit....

The Results of the CloudFlare Challenge
Published on April 11, 2014 09:00PM by Nick Sullivan
http://blog.cloudflare.com/the-results-of-the-cloudflare-challenge [blog.cloudflare.com]

Huge problem, as I understand it, is that the various certificate authorities are not set up to handle the large demand of reissuing and revoking the keys that need changing, which some feel may be all of them. Some promoted comments on the second ArsTechnica article mentioned above are worth reading in this regard.

The big gap in information for many users of services, myself included, is when one should change passwords... ie, after the OpenSSL patch is installed, or after the patch/new-certificate combination (which would, I assume, also include revoking the old certificate)... or both.

The thing about the Cloudflare test is the huge number of requests it took. The attackers new for certain that a given server was vulnerable and had the IP and it still took the first attacker 2.5 million requests to pull a key off it.

The second attacker got it in 100,000 requests. But of course there were probably hundreds of people attacking that server and many of them probably sent hundreds of thousands of requests without pulling a key.

Not saying this isn't a big deal, but I actually find the Cloudflare test reassuring rather than alarming. When you think of the horsepower required to send that many requests and then process all the garbage from the buffer overflows until you finally get a key, this is pretty intensive work. That means that even if the exploit were known in the wild (big if), any would-be villains would probably focus on a small number of high-value systems - financial institutions, certificate authorities, large e-commerce merchants.

As for updating passwords, I would say both if it's a site where you could be seriously harmed by having access given away, blocked or stolen - so finances, email, registrars principally.

Also, this is yet another case where I am reminded of the importance of never duplicating passwords across different sites. Every password on every high-value login should be unique, long and random.

A number of commercial outfits have decided to band together and invest in open source projects such as openssl, perhaps in light of this vulnerability.

[linuxfoundation.org...]

The first project under consideration to recieve funds from the Initiative will be OpenSSL, which could receive fellowship funding for key developers as well as other resources to assist the project in improving its security, enabling outside reviews, and improving responsiveness to patch requests. CII was formed as a response to the Heartbleed security crisis; however, the Initiative’s efforts will not be restricted to security-related issues.

I was shocked to read a post from Steve Marquess of the OpenSSL Foundation that in a typical year the project would receive about $2000 in donations. That is hardly enough to cover costs of hosting and communications, and then I am not even speaking of compensation for the time and dedication the team members put in maintaining such an important piece of software.

Having a more robust funding scheme is absolutely necessary to prevent this type of bugs in the future in this and other critical infrastructural software and I am extremely happy with the tech giants' initiative to start the Core Infrastructure Initiative.

More info on the new funding is here: [webmasterworld.com...]

Indeed, $2k and clearly 'we' were heavily reliant on it.

The companies listed are sitting on a lot of cash, fair play to them for seeing that this is a wise allocation of resources... avoiding a repeat of this saves everyone the headache.

More info on the new funding is here: [webmasterworld.com...]
The title of that thread, as currently worded, isn't quite correct, and it misses the bigger picture.

The funding isn't directly to OpenSSL... it's establishing the "Core Infrastructure Initiative" (aka CII), in response to Heartbleed, and first funding goes to OpenSSL. The implications of Heartbleed were huge, as they involved the infrastructure of infrastructure... (to coin a phrase if someone hasn't already). Many very smart people recognized how critical and fragile that infrastructure currently is, and that open source was necessarily part of the long term fix.

I'll post more on that when I see whether the title gets changed, but I don't want to have two parallel discussions on CII.

IMO, that title and description should be...

Tech's biggest names fund "Core Infrastructure Initiative"
Heartbleed the canary in the coal mine for critical web infrastructure
[webmasterworld.com...]