Critical crypto bug exposes Yahoo Mail passwords Russian-roulette style

OpenSSL defect still exposing sensitive data even after patch is released.

Read the whole story

 

[Fblue]

Aurich[/url]":28n1164h]
I saw this. I wonder if they have swapped there SSL Cert yet? I would imagine Ars public key was compromised, everything else appeared to be.

Yes, we've updated all our certs.[/quote]

Thanks for the update!

 

[sryan2k1]

If you actually read the thread, you'd see that Ars updated their servers this morning within hours of the news breaking. AKA - as soon as the admins became aware, and as soon as the OpenSSL patch was available.

Nice try.

Don't know that I'd call that "extremely vulnerable"

But you have no idea how far back data theft occurred. There is proof in one of the news feeds of people logging in as other Ars users using this bug as of this morning. That could have been happening for months with nobody knowing.

 

[GreenMeters]

Is there any 100% sure way for users to check a website's certificate and verify that it was generated by an SSL tool/version without known vulnerabilities?

 

[Kevinv]

Fastmail.fm updated their SSL and certs this morning. I changed my password there when they announced it.
Last I checked Lastpass had updated SSL but not their certs (they we're waiting on delivery of them) but user data is all encrypted anyway and only does decryption client side. So no worries there.

Haven't heard about Dropbox or Google Drive. Holding off on changing my passwords for those.

My personal server i updated SSL last night (Gentoo had it masked but released it this morning). I've decided to skip updating my certs at the moment. a) i get like 10 hits a day, b) ssl isn't actually protecting passwords, i just like having a SSL site to increase the amount of encryption on the internet.

SSL Labs also tests for this vulnerability now as well:
https://www.ssllabs.com/

 

[another ars account]

GreenMeters[/url]":2k5d5vvx]Is there any 100% sure way for users to check a website's certificate and verify that it was generated by an SSL tool/version without known vulnerabilities?

The concern isn't that the key was generated on a vulnerable server (although there is a bunch of potential issues there, if the CA really sucks) but that the private key for the cert was installed for use on a server that was vulnerable. The CA never even sees your private key when they sign your public key, and it's the private key that is in immediate danger here.

 

[Kevinv]

GreenMeters[/url]":132a63xa]Is there any 100% sure way for users to check a website's certificate and verify that it was generated by an SSL tool/version without known vulnerabilities?

it's not the SSL tool that generated the cert that's vulnerable. It's that the cert private key may have been leaked by this bug in the software.

Any cert with a valid from date before today is suspect. Go to the site, bring up the certificate information in your browser and check the valid from date. For example, below is fastmail.fm's certs. You'll see the start date as today.

 

[SAI Peregrinus]

Solomonoff's Secret[/url]":3j47klvm]Bugs like this don't happen in memory-managed languages like Java. If we insist on writing our security software in C, perhaps it should be written in a variant that enforces the validity of memory accesses at runtime. Performance would suffer negligibly compared to the security benefit. Unfortunately certain operations would have to be disallowed but the resulting inconvenience is a small price to pay.

Java doesn't work, code written with it is vulnerable to garbage collection attacks. You have to have a language that's low-level enough to keep the keys in memory, prevent them being paged to disk, and keep them from being copied somewhere by a GC. That's why C gets used. Ideally some mix (non-garbage collected but with automatic bounds checking) would be used.

 

[armwt]

sryan2k1[/url]":s9hykz9v]

If you actually read the thread, you'd see that Ars updated their servers this morning within hours of the news breaking. AKA - as soon as the admins became aware, and as soon as the OpenSSL patch was available.

Nice try.

Don't know that I'd call that "extremely vulnerable"

But you have no idea how far back data theft occurred. There is proof in one of the news feeds of people logging in as other Ars users using this bug as of this morning. That could have been happening for months with nobody knowing.

Fair point, but I'd still argue that Ars was "as secure" as they could expect to be, given that they patched the system within hours of the public release of the vulnerability. You're 100% right - we don't know (yet) how long this flaw has been out there, and being exploited, but the post I was replying to seemed to suggest that Ars was, essentially, a "very vulnerable" site that didn't take security seriously. I'd argue otherwise.

 

[SuperJB]

I didn't mean to be a bully about this programming error. I'm only suggesting that an understaffed and funding starved project that also just happens to run the Internet ... well that could be ripe for abuse. If OpenSSL is so important then it needs more eyes and accountability.

 

[invertigo]

RRob[/url]":2tep0d6z]You could have used Yahoo as an example without making the article title suggest it's an issue particular to them.

Yahoo was significantly slower (like 17 hours or so) to patch than any of the other major email providers.

 

[Kevinv]

SunnyD[/url]":3ttzprzt]... The entire Android ecosystem relies on OpenSSL if I am not mistaken, probably iOS too ...

Imagine how many "outdated" phones that are still in use will never get firmware update to fix this issue.

this is a server side issue, not a client issue. OpenSSL provides both server and client libraries and that is why Android and iOS use them. Unless you're serving web pages from your phone you're OK.

 

[Roguish]

invertigo[/url]":1tw8hkaq]

RRob[/url]":1tw8hkaq]You could have used Yahoo as an example without making the article title suggest it's an issue particular to them.

Yahoo was significantly slower (like 17 hours or so) to patch than any of the other major email providers.

Does this mean they are now in fact patched? I see their cert with a valid date of 4/7, and this story written just an hour and a half ago is warning you against logging in to Yahoo.

I just want to make sure when I should finally bother changing my password.

 

[dfjdejulio]

longhairedboy[/url]":3fynt2j2]its tempting to fire up my own mail server again.

I did that. On Linux. It was vulnerable.

(I patched it pretty quickly, though.)

 

[Archangel Mychael]

bthylafh[/url]":35gzrlcz]

sryan2k1[/url]":35gzrlcz]

bthylafh[/url]":35gzrlcz]My router firmware (Tomato/Shibby v1.16) is vulnerable. I've shut off remote access to the web console until this gets resolved.

You shouldn't have remote access to your router enabled in the first place.

I don't care. It's all over HTTPS and it's a good password, and it lets me remotely wake a computer if it's nodded off.

*Headdesk*

 

[dizdizzie]

This is terrible news. I used to have fun with OpenSSL on Ubuntu at Uni year ago or so and I thought that such widely used and critical software can be trusted. This is second time in past few weeks where critical bug is found in crypto/cert software, I thought as long as I stay away from things Java I could be relatively safe. Now I don't know anything.

 

[Deleted member 399649]

And yet here we are, still using passwords.

 

[Kasoroth]

Kevinv[/url]":37eq8lvh]

GreenMeters[/url]":37eq8lvh]Is there any 100% sure way for users to check a website's certificate and verify that it was generated by an SSL tool/version without known vulnerabilities?

it's not the SSL tool that generated the cert that's vulnerable. It's that the cert private key may have been leaked by this bug in the software.

Any cert with a valid from date before today is suspect. Go to the site, bring up the certificate information in your browser and check the valid from date. For example, below is fastmail.fm's certs. You'll see the start date as today.

I wonder if any of the browsers will be updated to automatically reject any older certificates as a precaution, or at least display a warning, so users know the connection is potentially compromised.

 

[longhairedboy]

Archangel Mychael[/url]":2hu4d5p7]

bthylafh[/url]":2hu4d5p7]

sryan2k1[/url]":2hu4d5p7]

bthylafh[/url]":2hu4d5p7]My router firmware (Tomato/Shibby v1.16) is vulnerable. I've shut off remote access to the web console until this gets resolved.

You shouldn't have remote access to your router enabled in the first place.

I don't care. It's all over HTTPS and it's a good password, and it lets me remotely wake a computer if it's nodded off.

*Headdesk*

There there....

 

[dangoodin]

Kevinv[/url]":lyivzsos]

SunnyD[/url]":lyivzsos]... The entire Android ecosystem relies on OpenSSL if I am not mistaken, probably iOS too ...

Imagine how many "outdated" phones that are still in use will never get firmware update to fix this issue.

this is a server side issue, not a client issue. OpenSSL provides both server and client libraries and that is why Android and iOS use them. Unless you're serving web pages from your phone you're OK.

Hold on, please. I don't think your comment is accurate, and it may give some readers a false sense of security. According to multiple researchers I trust, Heartbleed is a client issue, also. See, e.g.:

https://twitter.com/cpu/status/453621581797806080

https://twitter.com/KevinSMcArthur/stat ... 9950974976

https://twitter.com/jaimeblascob/status ... 4384235520

https://twitter.com/scottamcintyre/stat ... 7718906880

Comment updated to report tweeted opinions from researchers.

 

[Deleted member 1]

Solomonoff's Secret[/url]":3ap6y246]Bugs like this don't happen in memory-managed languages like Java. If we insist on writing our security software in C, perhaps it should be written in a variant that enforces the validity of memory accesses at runtime. Performance would suffer negligibly compared to the security benefit. Unfortunately certain operations would have to be disallowed but the resulting inconvenience is a small price to pay.

The performance difference is not that negligible. My company moved parts of the project from C++ to C# and all of our beta customers are complaining about performance problems. The difference is really big.

This is not a tool selection problem. This is developer problem. It doesn't make sense to switch to different tool (programming language) just because the individual who used the tool was not very proficient in using it. Everyone who had substantial experience in this type of programming would be aware of possible buffer overflow problems and would take care to sanitize the input data that comes from untrusted source. This is not something really tricky and hard to see that somehow surprised developer. This is really basic stuff when you have experience working in this field.

Not every developer is created equal and there is no universal tool you can use to level the playing field. Current tendency to use inappropriate tools just to minimize impact of bad developers is slowly coming to an end. We hit 4GHz limit with CPUs and there is no "let's wait for next years hardware that will improve our performance".

 

[Sulla]

hangfirew8[/url]":2lt07hvv]Nagant Model 1895 revolver... from Russia... nice touch.

What's with the cartridge on the left though?

 

[aquasub]

Roguish[/url]":1babr8ie]

invertigo[/url]":1babr8ie]

RRob[/url]":1babr8ie]You could have used Yahoo as an example without making the article title suggest it's an issue particular to them.

Yahoo was significantly slower (like 17 hours or so) to patch than any of the other major email providers.

Does this mean they are now in fact patched? I see their cert with a valid date of 4/7, and this story written just an hour and a half ago is warning you against logging in to Yahoo.

I just want to make sure when I should finally bother changing my password.

Before the update, the Yahoo Mail cert was valid from March 2014 to April 11, 2014. After the update, the cert is from today to April 25, 2014.

 

[hangfirew8]

Sulla[/url]":vi8l3uyp]

hangfirew8[/url]":vi8l3uyp]Nagant Model 1895 revolver... from Russia... nice touch.

What's with the cartridge on the left though?

The 1895 uses a funky cartridge with an extended case that seals in the barrel breach... requiring a cylinder that moves up and back as well as rotates.

It also makes it suitable for use with silencers, since there is no gap between cylinder and barrel to vent.

 

[GreenMeters]

Kasoroth[/url]":29kn7hst]

Kevinv[/url]":29kn7hst]

GreenMeters[/url]":29kn7hst]Is there any 100% sure way for users to check a website's certificate and verify that it was generated by an SSL tool/version without known vulnerabilities?

it's not the SSL tool that generated the cert that's vulnerable. It's that the cert private key may have been leaked by this bug in the software.

Any cert with a valid from date before today is suspect. Go to the site, bring up the certificate information in your browser and check the valid from date. For example, below is fastmail.fm's certs. You'll see the start date as today.

I wonder if any of the browsers will be updated to automatically reject any older certificates as a precaution, or at least display a warning, so users know the connection is potentially compromised.

To make matters worse, it sounds like some websites are getting new certificates that are back-dated to whatever their previous certificate was (not sure why, maybe they have some agreement with the CA that has a fixed renewal period).

 

[rakkuuna]

dangoodin[/url]"07xdei3]

Kevinv[/url]"07xdei3]

SunnyD[/url]"07xdei3]... The entire Android ecosystem relies on OpenSSL if I am not mistaken, probably iOS too ...

Imagine how many "outdated" phones that are still in use will never get firmware update to fix this issue.

this is a server side issue, not a client issue. OpenSSL provides both server and client libraries and that is why Android and iOS use them. Unless you're serving web pages from your phone you're OK.

Hold on, please. I don't think your comment is accurate, and it may give some readers a false sense of security. According to multiple researchers I trust, Heartbleed is a client issue, also. See, e.g.:

https://twitter.com/cpu/status/453621581797806080

https://twitter.com/KevinSMcArthur/stat ... 9950974976

https://twitter.com/jaimeblascob/status ... 4384235520

https://twitter.com/scottamcintyre/stat ... 7718906880

Comment updated to report tweeted opinions from researchers.

I hope we get some kind of follow up on this to explain. "it does" is a bit too vague to go on. One of them give you a clue about connectin to "malicious" server. So maybe trying to connect to a fake server might give the owner of the server a possibility to attack the client? How likely is that compared to the shitstorm on the serverside? I understand "heartbeating" servers but how could that be done against client side?

 

[thornburg]

Yahoo is still at least partially vulnerable.

As of right now (4:04PM Eastern), *.login.yahoo.com still has an old certificate.

 

[Korpo]

Doesn't the fact that something like this--used by 2/3 of the sites out there, entirely open source, yet vulnerable for years--fly in the face of the assertion that "open source is more secure because anyone can audit it"?

 

[jarvis]

Aw crap thats my Yahoo email address!!!!!

Well not really, but I've logged in/out of Yahoo mail about a dozen times today so I'm sure it is out there somewhere now. Congratulations on whoever gets it, I need help managing my mail. I use that account mostly for signing petitions and writing Congress Critters. Be careful contacting your Senators, once they have your address expect them to email you every other day looking for a donation. It's ridiculous. And they are all the same, please fund me or else there is going to be a massive [Republican|Democrat] takeover in my state!!!!!

 

[Muti]

Having an old certificate does not inherently mean the site is/was vulnerable since some sites may not be utilizing the OpenSSL library for their TLS implementations (Microsoft's IIS for instance).

 

[jeromeyers2]

Am I mistaken in thinking that IIS and most Microsoft services aren't affected by this?

 

[rakkuuna]

How effective is revoking certificates? Don't the client apps need to check it by themselves? I wonder if they do it very often...

 

[daneren2005]

blissfulight[/url]":2tqmceg0]And yet here we are, still using passwords.

And what exactly is it that makes you think private keys or anything else would have been any more secure when they can get those in the memory dump as well?

 

[maxmurder]

Korpo[/url]":1zwwmjag]Doesn't the fact that something like this--used by 2/3 of the sites out there, entirely open source, yet vulnerable for years--fly in the face of the assertion that "open source is more secure because anyone can audit it"?

More secure in the sense that unnamed agencies could force whoever owns the proprietary code to deliberately weaken it and/or never disclose the vulnerability publicly. Nothing can really stop people making silly code mistakes, or bugs getting through open source or not.

 

[Thor Erik]

jeromeyers2[/url]":1pocv63p]Am I mistaken in thinking that IIS and most Microsoft services aren't affected by this?

That is correct, IIS is not affected by this.

 

[Fritzed]

Vigilante1024[/url]":2tly1jke]

Killer Orca[/url]":2tly1jke]I am doubly glad that I switched over to using a password manager. Makes it a lot easier to keep log in information unique.

Any word on vulnerability of hosted password manager services like lastpass? Even two factor auth is no guarantee if the second factor is tied to an email service that is also vulnerable...

The potential vulnerability of a service like lastpass is, to me, what renders it useless. I personally use a keepassDB synched between machines with spideroak. Even if somebody broke into my spideroak account or my personal computer, they couldn't decrypt the keepassDB.

Unfortunately, I know this isn't for everyone.

 

[Kasoroth]

Muti[/url]":3klg4j8y]Having an old certificate does not inherently mean the site is/was vulnerable since some sites may not be utilizing the OpenSSL library for their TLS implementations (Microsoft's IIS for instance).

Many sites were vulnerable though, and for a long time, which means that it seems reasonable for a browser to consider any older certs to be at risk. If the browsers start rejecting older certs, it would be an inconvenience for non-compromised sites because they would need to get a new cert to appease the browser, even though they weren't compromised, but the alternative is that browsers continue to accept certs that have a good chance of being compromised.

Since there's no way (that I can think of) for the browser to know whether a particular cert was ever at risk, it seems like rejecting older certs would be the least bad option.

 

[dangoodin]

jeromeyers2[/url]":3gat2zmp]Am I mistaken in thinking that IIS and most Microsoft services aren't affected by this?

Most researchers will avoid blanket statements such as "no other crypto libraries are affected" because it's hard to prove a negative. Given how long this bug went undetected in OpenSSL, who's to say IIS isn't vulnerable? That said, there are no reports of this vulnerability affecting IIS or any other crypto libraries.

 

[Jousle]

Tell me the truth doctor, how bad is it?

 

[SpecTP]

Killer Orca[/url]":1vufv62v]I am doubly glad that I switched over to using a password manager. Makes it a lot easier to keep log in information unique.

How is that pwd manager going to mitigate this flaw? The flaw basically allows the hacker to query the authentication process to dump the last entries in memory. So your pwd will potentially still be visible if it's part of that memory dump.

 

[freegeek]

Jousle[/url]":3aupo2zf]Tell me the truth doctor, how bad is it?

On a scale of 1 to 10, I would say 11. I'm still busy with dealing with crap on my servers. I did an attack together with a colleague on a server under our own control and within minutes we had logins and passwords. Dealing with this crap means not only updating your openssl libraries (the easy part) but also creating new certificates and dealing with the CA (the annoying part). I have to revoke my old certficates, create a new private key, create new CSR, upload them to the CA to sign them and finally replace the certificates and the private keys on the servers when the CA has does his job. When it comes to security bugs, this one is going to be a candidate for a top spot in the history books