dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
8865

Ian1
Premium Member
join:2002-06-18
ON

Ian1 to 19579823

Premium Member

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.
LanDroid2
join:2004-12-20
Cincinnati, OH

LanDroid2 to 19579823

Member

to 19579823

Alex Jones

Alex "My gut says it, it's never been wrong" Jones.
AsherN
Premium Member
join:2010-08-23
Thornhill, ON

AsherN to Ian1

Premium Member

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

dave to 19579823

Premium Member

to 19579823
said by 19579823:

Hey I have an OPEN MIND and think of all possibilities!!!

.... without regard to reality.

Steve
I know your IP address

join:2001-03-10
Tustin, CA

5 recommendations

Steve to 19579823

to 19579823

Re: Duh

said 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 there

Think 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

Telly Boot to Zoder

Premium Member

to Zoder

Re: Heartbleed - zero day critical bug in OpenSSL

In 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

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?

Chubbzie
join:2014-02-11
Greenville, NC
Hitron CDA3
(Software) OpenBSD + pf

Chubbzie to 19579823

Member

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?

Steve
I know your IP address

join:2001-03-10
Tustin, CA

Steve to Telly Boot

to Telly Boot

Re: Heartbleed - zero day critical bug in OpenSSL

said 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?"

siljaline
I'm lovin' that double wide
Premium Member
join:2002-10-12
Montreal, QC

siljaline to Zoder

Premium Member

to Zoder
NSA Said to Have Used Heartbleed Bug, Exposing Consumers
quote:
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

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

OZO to siljaline

Premium Member

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

GuruGuy to Zoder

Premium Member

to Zoder
Pretty good article. »www.tomsguide.com/us/hea ··· 588.html

Link 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

Steve
I know your IP address

join:2001-03-10
Tustin, CA

Steve

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

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

to Zoder
Layman's guide to heartbleed.
dave

dave to Steve

Premium Member

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

to dave

Re: Heartbleed - zero day critical bug in OpenSSL

KA 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???

Steve
I know your IP address

join:2001-03-10
Tustin, CA

Steve

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

deke40
deke40
Premium Member
join:2003-01-23
Texas

deke40 to Zoder

Premium Member

to Zoder
Click for full size
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

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

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...

Steve
I know your IP address

join:2001-03-10
Tustin, CA

1 recommendation

Steve

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.

Link Logger
MVM
join:2001-03-29
Calgary, AB

Link Logger to DarkSithPro

MVM

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

Steve
I know your IP address

join:2001-03-10
Tustin, CA

Steve to GuruGuy

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?
DarkSithPro (banned)
join:2005-02-12
Tempe, AZ

DarkSithPro (banned) to Link Logger

Member

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?

Steve
I know your IP address

join:2001-03-10
Tustin, CA

Steve

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.

Vchat20
Landing is the REAL challenge
Premium Member
join:2003-09-16
Columbus, OH

Vchat20

Premium Member

^ 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

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.

Link Logger
MVM
join:2001-03-29
Calgary, AB

Link Logger to DarkSithPro

MVM

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.