Ian1 Premium Member join:2002-06-18 ON |
to 19579823
Re: said by 19579823:IT WAS GOING ON FOR 2 YEARS AND NO ONE NOTICED?? The bug existed for that long. Had it been being actively exploited widely, I suspect someone would have noticed earlier. |
|
|
to 19579823
Alex JonesAlex "My gut says it, it's never been wrong" Jones. |
actions · 2014-Apr-11 12:58 pm · (locked) |
AsherN Premium Member join:2010-08-23 Thornhill, ON |
AsherN to Ian1
Premium Member
2014-Apr-11 12:59 pm
to Ian1
Re: I find it hard to imagine that the hacker community has known and exploited this bug for 2 years without any inkling it was being done. |
|
dave Premium Member join:2000-05-04 not in ohio
1 recommendation |
to 19579823
said by 19579823:Hey I have an OPEN MIND and think of all possibilities!!! .... without regard to reality. |
|
SteveI know your IP address
join:2001-03-10 Tustin, CA
5 recommendations |
to 19579823
Re: Duhsaid by 19579823:Hey I have an OPEN MIND and think of all possibilities!!! "mind"? Who is this guy that confessed?? He's the guy who committed the change to the GIT repository, a known member of the team. 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 write C code for a living, and this is the kind of programming bug that's exceptionally easy to make. It's not like there's a comment in the code: /* This is where we allow the NSA to read random memory */
/* PLEASE DON'T TELL ANYBODY!!!!!!!!!!!! */
It's just a damn bug, and the fix is obvious once you know the bug is thereThink about stuff going wrong in your house, maybe a water leak behind a wall. It's going on for years, but you didn't know about it, but once the leak presents itself it's obvious how to fix it. You'd think I were a moron if I asked Why did you allow this leak to go on for so long? THIS IS SUSPICIOUS.. |
|
Telly Boot Premium Member join:2002-05-15 Vancouver, BC |
to Zoder
Re: Heartbleed - zero day critical bug in OpenSSLIn terms of using 'closed source' as mentioned above, instead of Open Source - OpenSSL, I'm puzzled as to why the Canada Revenue Agency, equivalent to the IRS, is using OpenSSL when Canadian Banks and Credit Unions ( known for their cautious and methodical approach as an industry) apparently do not: they are not affected by this bug. i.e. the CRA should not be short of a buck in the way that a small non-profit running an information website maybe would be. CRA has shut its tax filing website down for an undetermined period, probably continuing over this weekend, which of course is during Tax Time, and I would see it as a more than a bit of an embarrassment... -Although I don't see the media jumping on them as yet. I guess a lot of overtime is being worked, so it's not really that cost-effective in the end. So - Am I right in thinking that Thawte was bought by Verisign and then Verisign was recently bought up by Symantec- i.e. - does this mean that there is a very limited number of providers in the 'proprietary' certificate industry? Also, how much did the CRA and other 'major players' like Amazon save by using OpenSSL in this case...??? I could see their motivation if it's in the millions. |
|
|
AsherN Premium Member join:2010-08-23 Thornhill, ON |
AsherN
Premium Member
2014-Apr-11 1:59 pm
It is not about the number of players in the certificate world. OpenSSL is the code that uses the certificate. CRA is using it because their farm of web servers is running on Linux. Would you rather they invest on Windows licenses for that?
What makes you think your bank is not affected? Because they didn't say? Because they were able to patch faster than the CRA? |
|
Hitron CDA3 (Software) OpenBSD + pf
|
to 19579823
Re: said by 19579823:Who is this guy that confessed?? Awesome Dude, I answered this question 6 posts above your post. Please everyone just remember 2 things: - OpenSSL is not the only SSL library available for multiple platforms. It justs happens to be the libraries that normally are chosen by developers to integrate with their packages or software. As an example alternative, NSS. - The date of the cert has little to actually do with anything unless you are sure that OpenSSL was used & it happened to be one of the vulnerable versions. Thats one reason I feel that the LastPass Heartbleed checker is a complete joke. The checker speculates as to being vulnerable or not based on the date of the cert, seriously look at this result: quote: Was vulnerable: Possibly (might use OpenSSL, but we can't tell) SSL Certificate: Possibly Unsafe (created 1 year ago at Mar 19 00:00:00 2013 GMT) Assessment: It's not clear if it was vulnerable so wait for the company to say something publicly, if you used the same password on any other sites, update it now.
How is that helpful? |
|
SteveI know your IP address
join:2001-03-10 Tustin, CA |
to Telly Boot
Re: Heartbleed - zero day critical bug in OpenSSLsaid by Telly Boot: I'm puzzled as to why the Canada Revenue Agency, equivalent to the IRS, is using OpenSSL CRA is not using OpenSSL; instead, they are using a service-delivery platform that happens to use OpenSSL as one of the bazillion moving parts under the hood. People shop for their platforms for a lot of reasons, including availability of good frameworks, etc. Likewise, If you bought a new car, I wouldn't wonder "Why are you using SteveCo brake lines?" |
|
siljalineI'm lovin' that double wide Premium Member join:2002-10-12 Montreal, QC |
to Zoder
NSA Said to Have Used Heartbleed Bug, Exposing Consumersquote: The U.S. National Security Agency knew for at least two years about a flaw in the way that many websites send sensitive information, now dubbed the Heartbleed bug, and regularly used it to gather critical intelligence, two people familiar with the matter said.
» www.bloomberg.com/news/2 ··· ers.html |
|
Ian1 Premium Member join:2002-06-18 ON |
Ian1
Premium Member
2014-Apr-11 3:32 pm
said by siljaline:two people familiar with the matter said. Three people familiar with the matter said the Martians were behind the bug. See how easy that is? Maybe. I don't know.... |
|
OZO Premium Member join:2003-01-17 |
to siljaline
said by siljaline:The U.S. National Security Agency knew for at least two years about a flaw Please remind me how they called those, who knew abut crime, but tried to hide it... |
|
GuruGuy Premium Member join:2002-12-16 Atlanta, GA |
to Zoder
Pretty good article. » www.tomsguide.com/us/hea ··· 588.htmlLink within that tells how to tell if a site WAS vulnerable. Enter a URL and then check the results: you'll be looking for "Supported TLS Extensions" under the "SSL/TLS" heading. If "RFC6520 heartbeat" is listed, then the site was vulnerable and you should consider changing your password for it. » toolbar.netcraft.com/site_report |
|
SteveI know your IP address
join:2001-03-10 Tustin, CA |
Steve
2014-Apr-11 4:50 pm
What if somebody is running some other SSL stack, one that implements the heartbeat correctly? |
|
GuruGuy Premium Member join:2002-12-16 Atlanta, GA |
GuruGuy
Premium Member
2014-Apr-11 4:54 pm
said by Steve:What if somebody is running some other SSL stack, one that implements the heartbeat correctly? Good question. Is there a complete list of those other stacks? |
|
dave Premium Member join:2000-05-04 not in ohio
1 recommendation |
dave to Zoder
Premium Member
2014-Apr-11 5:02 pm
to Zoder
|
|
dave |
dave to Steve
Premium Member
2014-Apr-11 5:06 pm
to Steve
Re: Duh/* This is where we allow the NSA to read random memory */ This might be a useful technique if you want to get your code reviewers to pay a little more attention to what they're doing. |
|
OZO Premium Member join:2003-01-17 |
OZO to dave
Premium Member
2014-Apr-11 5:26 pm
to dave
Re: Heartbleed - zero day critical bug in OpenSSLKA packet could contain just 1 byte. And that would be enough for the purpose to keep connection alive. I've seen KA packets implementations a lot and have developed some in the past.
Instead developer has designed a scoop to get data from server side... It's obvious if one can specify the size of the "scoop" (size of data to be returned in range of 64KiB) separated from the actual data supposed to be sent back... It's very interesting - why??? |
|
SteveI know your IP address
join:2001-03-10 Tustin, CA |
Steve
2014-Apr-11 5:35 pm
said by OZO: Instead developer has designed a scoop to get data from server side... No, it wasn't designed for that, though there are legitimate questions about whether the payload feature is worthwhile. When you send your request, you send the byte count (say, 10) and you also provide 10 actual bytes of payload to go with it - you get to decide what they are there for. An example off the top of my head is that you could put a timestamp in the payload so you can computer round-trip times for the connection. The server, if it supports heartbeat, replies with the exact same 10 bytes you provide, sending them right back to you. The bug is that if I tell them "here are 1000 bytes" but only provide 5 actual bytes, the server will send me back 1000 bytes as I requested, with my provided payload as the first 5, and whatever 995 bytes happen to reside beyond it. These might be junk, they might be gold. That the heartbeat code didn't verify that the claimed count matches the actual count is a classic bounds-checking error, an exceptionally common and easy mistake to make in C. The proper behavior — as specified in the RFC — is to insure that the counts all match, and if they don't to just drop the packet on the floor - this is what the recently-released fix does. Steve |
|
deke40deke40 Premium Member join:2003-01-23 Texas |
to Zoder
Now if I get one of these from my other critical sites I will rest somewhat easier. |
|
dave Premium Member join:2000-05-04 not in ohio |
dave to Steve
Premium Member
2014-Apr-11 6:04 pm
to Steve
RFC 6520 says that the variable-size payload can be used for path MTU discovery - i.e., a heartbeat is not just a keepalive. -- Re: the length. It is explicitly needed because the entire rest-of-message is not all payload, so it's the only way to tell how large the payload (stuff to be echoed by receiver) actually is. And like every other message with nested fields, the receiver needs to check that the embedded entity does not fall off the end of the thing that contains it. (Easy for me to be smug, it's not my bug ) |
|
OZO Premium Member join:2003-01-17 |
OZO to Steve
Premium Member
2014-Apr-11 6:11 pm
to Steve
said by Steve:The bug is that if I tell them "here are 1000 bytes" but only provide 5 actual bytes, the server will send me back 1000 bytes as I requested, with my provided payload as the first 5, and whatever 995 bytes happen to reside beyond it. These might be junk, they might be gold. It doesn't work this way. If client tells to the server, that it sends 1000 bytes of data, server should wait for 1000 bytes of data to receive... Or drop the request completely. If specs allows client to ask server for specific amount of data to be sent back (why it's even allowed to do that???), than it's server's responsibility to fill that data correctly (and, of course, not by taking it from any random place of memory - it'd be old buffer overflow mistake, discussed abundantly many years ago). If it's true, the speck is just asking for exploit to happen... |
|
SteveI know your IP address
join:2001-03-10 Tustin, CA
1 recommendation |
Steve
2014-Apr-11 6:14 pm
said by OZO: It doesn't work this way. If client tells to the server, that it sends 1000 bytes of data, server should wait for 1000 bytes of data to receive... Or drop the request completely. No, it does work that way: This is the bug. Once the fixed the bug, it worked as you suggest it ought. |
|
|
to DarkSithPro
Code is hard, doesn't matter if its open source, closed source or whatever source and secure code is even harder. The problem is ultimately money and companies like Microsoft invest some of the money they earn into hiring and paying guys like Michael Howard for example to spend time reviewing code and more importantly learning how to review code and building tools etc to help with code reviews and security etc. There is nothing wrong with the idea of Open Source software, I've done it, but sometimes there is no substitute for paying someone to acquire and practice an expertise (ie take it beyond a hobby or just a learning experience or passing interest). OpenSSL has discovered the same problem that everyone has, you might build it, and people might use it, but it certainly doesn't mean people will support it or otherwise help pay for it. Apparently huge chunks of the internet include chunks which are for profit, aren't kicking back any money to help pay for or otherwise enhance or encourage the tools they are using to make buckets of money with. I'm not sure why companies think this is acceptable, as they certainly wouldn't think of using free Legal-Aid with their corporate legal requirements or get free executives (I'm waiting to see this), but for whatever reason people have the idea that software should be free firmly entrenched in their mindset, perhaps because they mistakenly assume code is easy and anyone can do, which I can assure you is a hugely incorrect assumption. I feel for the guy who coded this problem as from what I can understand at the time he was a university student and just cutting his teeth in coding, and really pretty good stuff for someone starting off, and I'm sure he feels like hell right now, but what do you expect for free?
Blake |
|
SteveI know your IP address
join:2001-03-10 Tustin, CA |
to GuruGuy
said by GuruGuy: If "RFC6520 heartbeat" is listed, then the site was vulnerable and you should consider changing your password for it. Another reason this is not dispositive. Even those running vulnerable OpenSSL, and those who had heartbeat enabled, might still have configured their package to support heartbeat only from server to client, refusing peer requests. This capability is advertised during the Client/ServerHello process though I suspect it's exceptionally rare for somebody to purposely turn this off (to advertise that the server might send a heartbeat request, but that it won't accept it from the client). See what happens when you read the RFC? |
|
|
to Link Logger
said by Link Logger:Code is hard, doesn't matter if its open source, closed source or whatever source and secure code is even harder. The problem is ultimately money and companies like Microsoft invest some of the money they earn into hiring and paying guys like Michael Howard for example to spend time reviewing code and more importantly learning how to review code and building tools etc to help with code reviews and security etc. There is nothing wrong with the idea of Open Source software, I've done it, but sometimes there is no substitute for paying someone to acquire and practice an expertise (ie take it beyond a hobby or just a learning experience or passing interest). OpenSSL has discovered the same problem that everyone has, you might build it, and people might use it, but it certainly doesn't mean people will support it or otherwise help pay for it. Apparently huge chunks of the internet include chunks which are for profit, aren't kicking back any money to help pay for or otherwise enhance or encourage the tools they are using to make buckets of money with. I'm not sure why companies think this is acceptable, as they certainly wouldn't think of using free Legal-Aid with their corporate legal requirements or get free executives (I'm waiting to see this), but for whatever reason people have the idea that software should be free firmly entrenched in their mindset, perhaps because they mistakenly assume code is easy and anyone can do, which I can assure you is a hugely incorrect assumption. I feel for the guy who coded this problem as from what I can understand at the time he was a university student and just cutting his teeth in coding, and really pretty good stuff for someone starting off, and I'm sure he feels like hell right now, but what do you expect for free?
Blake Got a question for you LL, Steve and the other programmers in here. This site: » mashable.com/2014/04/09/ ··· ffected/ shows the affected websites. Notice not one of the banks and financial institutions use OpenSSL? Is there a reason for that? |
|
SteveI know your IP address
join:2001-03-10 Tustin, CA |
Steve
2014-Apr-11 6:44 pm
said by DarkSithPro: Notice not one of the banks and financial institutions use OpenSSL? Is there a reason for that? Nobody who's shopping for a website pays any attention to most of the moving parts underneath, instead adopting an entire platform. Many large commercial enterprises are .NET shops, which means they use Microsoft, and MSFT's webservers use a different TLS stack. This doesn't free them from all stack-related bugs, only this one. |
|
Vchat20Landing is the REAL challenge Premium Member join:2003-09-16 Columbus, OH |
Vchat20
Premium Member
2014-Apr-11 6:51 pm
^ This
And it honestly doesn't surprise me. Where you are going to see the heartbleed bug (and directly, OpenSSL usage) is largely going to be on servers using open source HTTP servers ala Apache, nginx, lighttpd, etc..
Banking institutions historically use Microsoft software in this regard. Closed source, trusted, and a scapegoat to fall back on in case something goes tits up due to a software issue. Amongst other business related reasonings that I am not privvy to. |
|
dave Premium Member join:2000-05-04 not in ohio |
dave to OZO
Premium Member
2014-Apr-11 7:00 pm
to OZO
said by OZO:It doesn't work this way. If client tells to the server, that it sends 1000 bytes of data, server should wait for 1000 bytes of data to receive... You need understand the concept of 'message'. This is a message-oriented exchange. A length that is the length of something in the message does not permit 'waiting' for some other miracle to supply the data. If specs allows client to ask server for specific amount of data to be sent back (why it's even allowed to do that???), The spec does not (directly) allow that. The length value we are discussing is the length of data provided in the request. A length that exceeds the length of the containing message is, of course, illegal. The bug was failing to check for valid nesting. It's a simple bug. The length was only implicitly the length of data to be sent back; the length of the return is defined as exactly equal to the length of data sent (after message validation, naturally). Speculation is not needed, the RFC is particularly simple. |
|
|
to DarkSithPro
Sometimes free isn't good enough as you want to know someone is getting paid to do the icky stuff that helps cover your butt.
Good thing Google paid for a researcher to finally look into this otherwise we wouldn't be having this conversation now.
Blake edit - I wonder why Google's researcher was poking around in this area of OpenSSL, I wonder if Google's admins saw something in their logs which tipped them off that perhaps they should take a peek at this code. Just Wondering. |
|