EEVblog Electronics Community Forum
General => General Technical Chat => Topic started by: Crazy Ape on April 09, 2014, 03:55:27 pm
-
Heartbleed
Heads up. The internet has been compromised.
http://www.news.com.au/technology/heartbleed-bug-in-openssl-renders-internet-insecure/story-e6frfrnr-1226878634218 (http://www.news.com.au/technology/heartbleed-bug-in-openssl-renders-internet-insecure/story-e6frfrnr-1226878634218)
http://www.thewire.com/technology/2014/04/what-you-need-to-know-about-heartbleed-the-new-security-bug-scaring-the-internet/360366/ (http://www.thewire.com/technology/2014/04/what-you-need-to-know-about-heartbleed-the-new-security-bug-scaring-the-internet/360366/)
http://www.smh.com.au/it-pro/security-it/web-security-in-doubt-after-discovery-of-heartbleed-flaw-20140409-zqsif.html (http://www.smh.com.au/it-pro/security-it/web-security-in-doubt-after-discovery-of-heartbleed-flaw-20140409-zqsif.html)
-
Checking -> http://possible.lv/tools/hb/?domain=www.eevblog.com (http://possible.lv/tools/hb/?domain=www.eevblog.com) ... ah, not vulnerable & secured, great ! :-+
Since I put all passwords including my Cayman Island bank accounts synched with eevblog.com password. >:D
-
Just versions 1.0.1 and 1.0.2beta got that issue. Sites running those versions have to update OpenSSL and also issue new SSL certificates (incl. signing by a CA if not selfsigned).
-
Now would be a good time for a PKI authentication standard for the web.
-
Checking -> http://possible.lv/tools/hb/?domain=www.eevblog.com (http://possible.lv/tools/hb/?domain=www.eevblog.com) ... ah, not vulnerable & secured, great ! :-+
www.eevblog.com (http://www.eevblog.com) doesn't support SSL at all ;)
Since I put all passwords including my Cayman Island bank accounts synched with eevblog.com password. >:D
Everyone knows that it's 'secret' :-DD
-
Since I put all passwords including my Cayman Island bank accounts synched with eevblog.com password. >:D
Everyone knows that it's 'secret' :-DD
Damn, I am busted !!! :'(
Do you somehow have affiliation with NSA's branch in Germany ? The one who did Merkel's phone ? :-DD
-
Do you somehow have affiliation with NSA's branch in Germany ? The one who did Merkel's phone ? :-DD
Psst! Not so loud! Some years ago I wrote software for the communication's metadata retention law which was dumped fortunately. The sofware is still running fine. >:D
PS: 'topsecret' isn't very smart either. :-DD
-
A website that can test if you are vulnerable.
https://www.ssllabs.com/ssltest/analyze.html (https://www.ssllabs.com/ssltest/analyze.html)
-
A website that can test if you are vulnerable.
https://www.ssllabs.com/ssltest/analyze.html (https://www.ssllabs.com/ssltest/analyze.html)
But the problem is on the server side! right?
So what will they be testing?
-
But the problem is on the server side! right?
So what will they be testing?
You obviously haven't followed the link. It's a server test.
-
But the problem is on the server side! right?
So what will they be testing?
You obviously haven't followed the link. It's a server test.
That's my point, if the server is the one vulnerable, what are they testing? And I don't hit links randomly even if they are posted in this forum.
The vulnerability comes from the server using OpenSSL, so they have a server to test if other servers are compromised? or are they testing your machine.
And no, I won't hit the linky to see what the test is about :)
-
That's my point, if the server is the one vulnerable, what are they testing? And I don't hit links randomly even if they are posted in this forum.
The vulnerability comes from the server using OpenSSL, so they have a server to test if other servers are compromised? or are they testing your machine.
And no, I won't hit the linky to see what the test is about :)
Quote from the page:
"This free online service performs a deep analysis of the configuration of any SSL web server on the public Internet."
-
Quote from the page:
"This free online service performs a deep analysis of the configuration of any SSL web server on the public Internet."
Thanks for the info, so before I use any https site, I should test it via that service.
I was replying to:
A website that can test if you are vulnerable.
https://www.ssllabs.com/ssltest/analyze.html (https://www.ssllabs.com/ssltest/analyze.html)
That's why I got confused, specially since the testing site is https :)
Stay away from my 64K memory past your certificate! :box:
-
Quote from the page:
"This free online service performs a deep analysis of the configuration of any SSL web server on the public Internet."
Thanks for the info, so before I use any https site, I should test it via that service.
It will show you if a web server is still vulnerable. Many have been fixed already.
I was replying to:
A website that can test if you are vulnerable.
https://www.ssllabs.com/ssltest/analyze.html (https://www.ssllabs.com/ssltest/analyze.html)
That's why I got confused, specially since the testing site is https :)
Stay away from my 64K memory past your certificate! :box:
Keep in mind that while OpenSSL is used by a great many hosts, there is more than one way to provide https and that the 'Heartbleed' flaw is OpenSSL specific.
http://en.wikipedia.org/wiki/Comparison_of_TLS_implementations (http://en.wikipedia.org/wiki/Comparison_of_TLS_implementations)
-
Yup I knew that. I guess I was being a bit facetious.
I know SSL and TLS pretty well but Qualys is not really a qualified agent for security. Well, I guess they think they are ;)
Anyhow, yeah, it's pretty serious because a lot of companies don't want to pay for professional software and they go open sore.
-
Anyhow, yeah, it's pretty serious because a lot of companies don't want to pay for professional software and they go open source.
There are more problems with closed source software, just look at Micro$oft. ;D
Many more eyes pass over open source code, and when something does slip through, it's generally fixed much sooner than a bug in closed source software.
-
Anyhow, yeah, it's pretty serious because a lot of companies don't want to pay for professional software and they go open source.
There are more problems with closed source software, just look at Micro$oft. ;D
Many more eyes pass over open source code, and when something does slip through, it's generally fixed much sooner than a bug in closed source software.
Sure it does, like removing code so that the process id was used to seed of the random number for the SSL handshake, shees! And no that wasn't M$
suddenly many companies will take the same public keys :-DD
and I didn't misspell source, I really meant "open sore" on purpose, not sure why you edited the quote.
-
and I didn't misspell source, I really meant "open sore" on purpose, not sure why you edited the quote.
I'm not sure why either, I don't usually do that sort of thing, I should have just questioned your spelling, sorry.
-
It's ok, but don't rely on the many eyes looking, usually Open Source projects are really maintained by only a few people and they always rely on others to catch the problems, so none of them do.
The PID problem was years in the making so was the heartbeat, and guess what. IIS is not affected, go figure.
-
http://privatekeycheck.com/ (http://privatekeycheck.com/)
>:D >:D >:D
Alexander.
-
It's ok, but don't rely on the many eyes looking, usually Open Source projects are really maintained by only a few people and they always rely on others to catch the problems, so none of them do.
The PID problem was years in the making so was the heartbeat, and guess what. IIS is not affected, go figure.
Microsoft seems to have hit it's stride recently ... but IIS 7.5 and it's multiple remote exploits aren't that long ago. There's plenty of exploits to go around.
In my opinion what this shows is that software with the complexity of OpenSSL shouldn't be trusted with secret keys ... keys you really want to keep secret shouldn't be on the same physical machine as some 100K+ LOC exploit waiting to happen (not logins either really, but because the web is retarded you can't easily take the web server out of the loop for this).
-
In my opinion what this shows is that software with the complexity of OpenSSL shouldn't be trusted with secret keys ... keys you really want to keep secret shouldn't be on the same physical machine as some 100K+ LOC exploit waiting to happen (not logins either really, but because the web is retarded you can't easily take the web server out of the loop for this).
I assume you're talking about the private key. Unfortunately the server needs to know the private key to be able to setup the SSL session (proof of identity). And since everything has to work automatically the private key isn't protected by a passphrase. But the whole CA system is broken anyway :-(
-
I assume you're talking about the private key. Unfortunately the server needs to know the private key to be able to setup the SSL session (proof of identity). And since everything has to work automatically the private key isn't protected by a passphrase. But the whole CA system is broken anyway :-(
Seems some work has been done to use HSMs with OpenSSL, dunno how practical it is ... although the alternative wasn't very practical either in retrospect.
-
This looks good, I tried btinternet.com which is the service provider I use and got this. "Assessment failed: No secure protocols supported"
-
It's ok, but don't rely on the many eyes looking, usually Open Source projects are really maintained by only a few people and they always rely on others to catch the problems, so none of them do.
The PID problem was years in the making so was the heartbeat, and guess what. IIS is not affected, go figure.
Many huge companies make use of OpenSSL in their commercial products, even as a key component. One example being Juniper; their SSL VPN appliances were vulnerable. If the source code has not been looked at by these large users with large development teams and their own internal security audits, the length of this vulnerability's exposure lies at their feet as much as at the original developer's.
The existence of this vulnerability has absolutely nothing to do with whether the source is open or not, but I would say the swiftness with which the fix has been / is deployed to integrated products such as the Juniper one mentioned above, as well as operating systems, is directly attributable to the source being available. As is the transparency around exactly what the vulnerability is, and how it might be exploited, which leads directly to tools like the ones linked in this thread being available.
-
Does anyone have an idea where the opps'd code came from?
-
Does anyone have an idea where the opps'd code came from?
This is the commit: http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c5082161b02a22116ad75f822b1 (http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c5082161b02a22116ad75f822b1)
-
I'd hate to be that guy now.
Makes me wonder if this was an honest mistake. I've been there before with some of my coding -- what memory leak?
But I can't help to think of the NIST/NSA Elliptic Curve "backdoor": http://en.wikipedia.org/wiki/Dual_EC_DRBG (http://en.wikipedia.org/wiki/Dual_EC_DRBG)
-
There's a brief article about the guy here (http://www.smh.com.au/it-pro/security-it/man-who-introduced-serious-heartbleed-security-flaw-denies-he-inserted-it-deliberately-20140410-zqta1.html), if you're curious. Not much of substance in there though.
Yeah, with the current US surveillance state environment, it's hard not to draw parallels. It'd be interesting to see how they managed it though, considering the committer is a Brit and the author (including of the RFC being implemented) is German. Both security experts with long histories in the open source community who I wouldn't suspect to go willingly with an NSA conspiracy. So for now I'm going with just an accident...pending more Snowden papers, of course :P.
-
He does say that not enough people get in and get their hands dirty with developing and reviewing open source software. I hope the conspiracy theorists, who I also don't think tend to make much of an effort to contribute, don't discourage people from being willing to help.
I agree with the sentiment. But how can you? Especially on topics like this? I mean this guy has a PhD in mathematics.
reCaptcha for Code?
-
Who hasn't made a simple mistake like this? The guy has given an interview and comes across to me as an academic who plays with a straight bat.
Guy has a PhD, and later on went on to work for a company with some ties to the German government. Auditor of the commit was another guy with a PhD from the UK.
As many coming from the practical side of things know, you should not let someone with a PhD near a compiler or near code at all. It does not end well.
What let people scratch their head a bit is that the error is not only simple, but an obvious violation of one of the fundamental principles of writing good code: Never trust input.
It is also a bit strange that the RFC 6520 with the heartbeat extension was so quickly rubber-stamped, was authored with the help of the same guy who committed the code, and has at least two fundamental errors . Errors one would have expected would have to be caught by the master experts and guardians of the Internet protocols in the IETF who sanctioned it.
It is actually a fine study that bugs often don't start in the code, but in the specification.
Error 1 in the RFC: Not using TCP's keep-alive on TCP, and just defining something similar and simple for UDP.
Error 2 in the RFC: Having a payload part.
Especially that a payload part was added is strange. And that the same guy then messed up the implementation.
-
Especially that a payload part was added is strange. And that the same guy then messed up the implementation.
It's really not that strange. Even the venerable ICMP ping message has a payload.
-
Especially that a payload part was added is strange. And that the same guy then messed up the implementation.
It's really not that strange. Even the venerable ICMP ping message has a payload.
RTFRFC. The purpose of the payload is pretty clear. It is intended to facilitate PMTUD over DTLS. You can argue that it's better to implement such a feature only in DTLS and not TLS, but it is equally arguable that the same code and logic paths should be used for both protocols where possible (ironically, to minimize the attack surface and thus likelihood of bugs just like this one).
Anyway even if you excluded this functionality from TLS entirely and implemented it differently there, DTLS would still be vulnerable, so this doesn't really have anything to do with the RFC. It was a stupid coding error that could happen when implementing any RFC, not just this one.
The feature creep argument is perhaps a good one, but that is a much tougher nut to crack, and it's not so easy to place the blame, there's plenty to go around.
The code was sloppily written, sloppily reviewed, committed and forgotten. Seems to be pretty much it.
-
Ok, so what's the real deal with this thing, is it such a big deal?
How many people or sites have been hacked so far?
How does changing your password help if a site hasn't patched it?
-
Ok, so what's the real deal with this thing, is it such a big deal?
How many people or sites have been hacked so far?
How does changing your password help if a site hasn't patched it?
There is the potential that any private data stored on a secure server (running OpenSSL) over the last two years is compromised.
No one knows who may have discovered and been using the flaw prior to it being 'found' and publicly announced.
Web Security companies are taking the 'Assume the worst' road to be safe.
The tech side (in short):
The flaw allows an attacker to grab copies of server memory 64Kb at a time, this could contain anything from user credit data, to the servers own SSL certificate.
There is little point in changing your password until the server is fixed.
-
The problem, easily explained by xkcd.
http://xkcd.com/1354 (http://xkcd.com/1354)
-
Ok, so what's the real deal with this thing, is it such a big deal?
How many people or sites have been hacked so far?
How does changing your password help if a site hasn't patched it?
according to bruce schneier, out of a 1-10 range, 10 being bad, he rates this an eleven. no, this is not a spinal tap reference ;)
he's not usually alarmist, either.
fwiw
-
Ok, so what's the real deal with this thing, is it such a big deal?
How many people or sites have been hacked so far?
How does changing your password help if a site hasn't patched it?
according to bruce schneier, out of a 1-10 range, 10 being bad, he rates this an eleven. no, this is not a spinal tap reference ;)
he's not usually alarmist, either.
fwiw
The OpenSSL group even produced a logo for the problem. Honest graphic design. I mean... have you seen this group's website? That's big. :)
-
Tech giants, chastened by Heartbleed, finally agree to fund OpenSSL, create three-year initiative with at least $3.6 million to help under-funded open source projects.
http://www.linuxfoundation.org/programs/core-infrastructure-initiative (http://www.linuxfoundation.org/programs/core-infrastructure-initiative)
Alexander.
-
[Do you somehow have affiliation with NSA's branch in Germany ? The one who did Merkel's phone ? :-DD
Apparently the German government has similar capabilities
http://www.reuters.com/article/2014/08/15/us-germany-usa-spying-idUSKBN0GF1RV20140815?irpc=932 (http://www.reuters.com/article/2014/08/15/us-germany-usa-spying-idUSKBN0GF1RV20140815?irpc=932)