The guy who lodged the bug had his say: as he pointed out, the code reviewer missed the problem as well, and it is entirely possible that nobody else looked carefully at the code because the number of people actively working on patches and improvements to openssl is very small - certainly as a percentage of the number of people who happily use it for free.
Rather than saying that the incident is an argument for closed source the takeaway is that if large for-profit companies who make billions using these products could perhaps devote just ONE staff member each to QA of submitted patches, then things would be a lot more secure. I bet many CTOs don't care to understand the open source building blocks they use, if they don't show up as an expense they think it is someone else's problem.
Let's see how many millions of dollars worth of time and productivity are wasted while people change passwords unnecessarily due to media overreaction and misinformation.
Rather than saying that the incident is an argument for closed source the takeaway is that if large for-profit companies who make billions using these products could perhaps devote just ONE staff member each to QA of submitted patches, then things would be a lot more secure.
I don't think anyone was implying this and nobody has actually said it (that I have seen). I take it more as a counter to the constant "open source is better because. . ." which is not the same argument.
I bet many CTOs don't care to understand the open source building blocks they use, if they don't show up as an expense they think it is someone else's problem.
The guy who lodged the bug had his say: as he pointed out, the code reviewer missed the problem as well, and it is entirely possible that nobody else looked carefully at the code because the number of people actively working on patches and improvements to openssl is very small - certainly as a percentage of the number of people who happily use it for free.
Rather than saying that the incident is an argument for closed source the takeaway is that if large for-profit companies who make billions using these products could perhaps devote just ONE staff member each to QA of submitted patches, then things would be a lot more secure. I bet many CTOs don't care to understand the open source building blocks they use, if they don't show up as an expense they think it is someone else's problem.
I dunno about that Justin. Link Logger hit the nail on the head and it brings up serious security questions about just how much more secure Open Source is vs Closed Source. This vulnerability has been out for for what, years now? Perhaps Closed Source can be just as secure as Open Source.
open source has always had tons of bugs, just like closed source has.
This is a unique situation because openSSL is a bit special and seems to have a very low density of people who understand the code compared to (say) the core of the linux kernel, or apache/nginx yet is clearly more important especially in an era where apparently we can't trust the government to actually want bug free crypto.
I am not going to bother to change my personal passwords that's a measure of how I think this bug impacts the majority of normal people (not people guarding large amounts of other peoples money, state secrets, or those looking to commit terrorism).
I have yet to hear about 1 person claiming to be impacted. A few years ago the Dept. of Revenue in SC was hacked and they got our tax returns which gave them all the info they could ever want. Also DSLR was hacked and they got our email and password. DSLR sent us a notice.
So until I hear about some impact from this I will wait before expending the time to change passwords. Besides, every so often I change my passwords on important sites as I am sure most of you do.
Unless you're replacing your SSL certificates, you should still be considered vulnerable and your keys compromised.
So, how does the average non-technical person know if the site they are going to was vulnerable in the first place or not?
And how would that person know that not only has the site been patched, but the SSL certificate been updated?
This only impacts OpenSSL v1.0.2-beta and less than 1.0.1g. It would be nearly impossible for anyone to know that not only was the site once vulnerable, but that the keys had been replaced.
Agree totally. Most of the test sites are saying "not vulnerable". They fail to mention if they WERE vulnerable. Scrolling down after seeing not vulnerable, you often see certs that clearly have not been updated.....in other words, you ARE still vulnerable. Patching the hole doesn't fix the stolen credentials that haven't been updated.
quote:Despite speculation that the Heartbleed flaw was deliberately created by government agencies to spy on us, a developer has now come forward and confessed to causing the problem.
quote:Despite speculation that the Heartbleed flaw was deliberately created by government agencies to spy on us, a developer has now come forward and confessed to causing the problem.
That's interesting. The article mentions that Google and Facebook had fixed the issue. From testing both, their certs have NOT been updated, so the issue is not "fixed".
After reading through my recent rants about test sites showing servers not vulnerable and yet the certificates are not updated...I'm now wondering if it matters?
If the heartbeat hole is plugged and you can't access the server anymore via that bug, what does it matter if the cert is updated. They can't access the server anyway.
So if you've changed your password and the server is patched, you should be fine.
If the cert was stolen back before the bug was patched then in theory someone could perform a man in the middle attack and "listen in" on connections. Note that if the site is using PFS then it needs to be an active MitM attack; passive listening won't get anything.
If the heartbeat hole is plugged and you can't access the server anymore via that bug, what does it matter if the cert is updated. They can't access the server anyway.
Because if they have the cert, there is a possibility that they can gain your new password (and any other data being 'protected' by the cert).
If the cert was stolen back before the bug was patched then in theory someone could perform a man in the middle attack and "listen in" on connections. Note that if the site is using PFS then it needs to be an active MitM attack; passive listening won't get anything.
/M
Even if sites revoke their old certs and issue new ones, an active attacker could just block the OCSP request for revocation checks. By default, most (if not all) browsers soft-fail OCSP timeout errors and other network errors.
The best most sites can hope for is that their certificates were due to expire soon or if they were added into Chrome's CRLSets. Just another reason why people shouldn't be creating certificates that last more than a single year.
Microsoft Services unaffected by OpenSSL "Heartbleed" vulnerability
quote:On April 8, 2014, security researchers announced a flaw in the OpenSSL encryption software library used by many websites to protect customers data. The vulnerability, known as Heartbleed, could potentially allow a cyberattacker to access a websites customer data along with traffic encryption keys. [...]
That's interesting. The article mentions that Google and Facebook had fixed the issue. From testing both, their certs have NOT been updated, so the issue is not "fixed".
There's a lot of fuzzy reporting out there, particularly failing to make the distinction between patching the bug and updating the certs.
If the heartbeat hole is plugged and you can't access the server anymore via that bug, what does it matter if the cert is updated. They can't access the server anyway.
Because if they have the cert, there is a possibility that they can gain your new password (and any other data being 'protected' by the cert).
So it's back to what I had been saying. Don't update passwords until the cert is also updated.
These websites need to stop reporting sites as being "fixed" when in fact their certs haven't been updated along WITH the bug patch.
The entity that has egg on its face is not 'open source' nor 'closed source' but 'code review'. From what I've heard, this was a bug in the conceptually trivial matter of parameter checking.
I review a lot of (proprietary) code. I suspect I would have missed this, because though I pay a lot of attention to silly details in the code from juniors, I tend to trust that the senior people know what they're doing on a micro level, so I can concentrate on the macro aspects.
(Mind you, I'd hope I would subject security code to a higher level of scrutiny, but I don't see any of that in my current position).
Code review is hard. About twice as hard as writing code. It's debugging without a debugger.
Something that seems to be missed in the discussion.
Certificates.
I hold a piece of paper with a wax seal on it. Does it mean any more than one without. History says yes.
So if you have a valid certificate than you are legit? Do I have to sit here and elaborate on that? Exploit aside, a replaced certificate is just that. Valid or not.
Does it mean you are ethical because you hold a valid certificate? I've never thought so, but ethics and the Internet are still young.
The entity that has egg on its face is not 'open source' nor 'closed source' but 'code review'. From what I've heard, this was a bug in the conceptually trivial matter of parameter checking.
I review a lot of (proprietary) code. I suspect I would have missed this, because though I pay a lot of attention to silly details in the code from juniors, I tend to trust that the senior people know what they're doing on a micro level, so I can concentrate on the macro aspects.
(Mind you, I'd hope I would subject security code to a higher level of scrutiny, but I don't see any of that in my current position).
Code review is hard. About twice as hard as writing code. It's debugging without a debugger.
It's a failure of coding.
Why code a keep-alive with a variable size payload? And why allow for such a large payload? If ping can get away with 32 bytes, why not keep-alive?
I've done coding, I've done code review. Even in code review, you may not look for all the "what if"
"Don't update passwords until the cert is also updated."
It isn't so simple. Certs can be (and some are being) replaced with the original FROM date. This is not the place to get into the why of it all, but the consequence is that unless you compare the before/after cert content you need to rely on the company official statement on whether they are fixed or not. For google (gmail etc) you DO need to change passwords.
"Don't update passwords until the cert is also updated."
It isn't so simple. Certs can be (and some are being) replaced with the original FROM date. This is not the place to get into the why of it all, but the consequence is that unless you compare the before/after cert content you need to rely on the company official statement on whether they are fixed or not. For google (gmail etc) you DO need to change passwords.
Google has not issued an official statement on whether or not to change your password. From some of the sites I've seen posting on this, google has apparently patched servers, but does not recommend changing password. At this point who knows what is true and where that info came from without an official Google response.
They dont care buddy,they are probably the ones BEHIND IT!!
I think this thing ACCIDENTLY LEAKED OUT so they had to rush and come up with a "Patch" so sheep would think it couldnt be done anymore!! (While they continue what they are doing)
I THINK ALL SITES SHOULD NOT BE USING OPENSSL!!!!!!!! -- WHY BLINDLY ACCEPT SOME PATCH WHEN YOU DONT KNOW 100% WHAT IS GOING ON???
I dunno.....Are you using OpenSSL on the cert here Justin?? (If you are,i strongly advise changing to a different provider -- DONT BLINDLY BELIEVE THEM THAT EVERYTHING IS OK WITH A SO CALLED "PATCH") -- I agree with Alex!!
They dont care buddy,they are probably the oens BEHIND IT!!
I think this thing ACCIDENTLY LEAKED OUT so they had to rush and come up with a "Patch" so sheep would think it couldnt be done anymore!!
C'mon Dude, the coder who introduced the bug has fessed up to his mistake and in coding stuff happens; even in the OSS community. Please exhaust the probable before you go for the fantastic unless you have the appropriate level of evidence for such a charge. Remember that extraordinary claims require the same level of evidence...
Hey I have an OPEN MIND and think of all possibilities!!!
Who is this guy that confessed??
The whole thing is quite suspicious..... IT WAS GOING ON FOR 2 YEARS AND NO ONE NOTICED?? -- Then all of a sudden they do and say its fixed with a patch??
Hey I have an OPEN MIND and think of all possibilities!!!
Who is this guy that confessed??
The whole thing is quite suspicious..... IT WAS GOING ON FOR 2 YEARS AND NO ONE NOTICED?? -- Then all of a sudden they do and say its fixed with a patch??
I DONT TRUST THAT,DO YOU?
SOMETHING ISNT RIGHT............
I said nothing about trust or lack thereof. I said do the leg-work and get the evidence to support your conclusions before you start claiming the sky is falling.