Heartbleed Bug: Serious Hole in Internet Security

[Brian Stirling]

I believe that's when the commit took place. It's really unlikely anybody knew about it before the disclosure. Schneier painted a picture of the NSA working furiously to exploit it since yesterday, which is probably closer to the truth.

Turns out, the NSA knew of the vulnerability for two years and HAVE been exploiting it.

It almost doesn't matter who coded the weakness as smart guys like they have at the NSA are looking for such things and will exploit them. They knew for two years and told no one!

So, believing they are acting in our best interest when the "help us" with coding net security is naive in the extreme...


Brian

 

[Crusty]

Mark, its clear you know nothing about the internet or computers. Rebooting a server does not do anything that was not done in the first place. In other words, when you turn a computer on it will do the same thing every time. In addition, I have studied this topic extensively and come to the conclusion that this is much ado about nothing.

I'll take your bait.

The OpenSSL malloc implementation used a LIFO queue to hand out buffers.

By rebooting the server you can be assured that the OpenSSL process HAS to read in all the private keys and store them in memory buffers.

As time goes on, more and more buffers are created and released, thus burying those initial buffers that were freed up in the LIFO queue. In my opinion, it certainly seems more likely you'll stumble upon a key after a reboot than you would find the key during normal operation.

 

[FelixDeCat]

no

 

[Crusty]

Lets assume your premise is correct, that a lack of buffers increases the likelihood of compromise after reboot.....then why not incorporate a sequence that generates "more and more buffers" that are "created and released" as part of that process?

Am I missing something here? Would Mark care to chime in on this?

Yeah, you're missing everything.

 

[CZroe]

I believe that's when the commit took place. It's really unlikely anybody knew about it before the disclosure. Schneier painted a picture of the NSA working furiously to exploit it since yesterday, which is probably closer to the truth.

Too bad he ended up being dead wrong.

Everyone is looking for abuse in the wild now that it has been divulged so it would be detected if they made a full-scale keygrab now.

Normally nothing is logged for SSL heartbeats, so very little from the past two years remains stored for analysis. What little is stored was just incidentally stored for other reasons and yet they've already found at least one Heartbleed attack from November of last year. If they found one you can bet that there were PLENTY more.

Furthermore, it was sent from an IP known to be used as a botnet. The botnet's purpose? Infiltrate and log every single Freenode IRC channel, which is an intelligence-gathering initiative if I have ever seen one. Even if that wasn't the NSA (IRC bots aren't exactly discrete), you can bet that they have at least the same intelligence-gathering abilities as whoever did it.

 

[Virgorising]

NSA says, No, we had no clue:

http://www.huffingtonpost.com/tech/

 

[bradley]

I call shens on the NSA. They have dismantled all code and have started at the top, pretty much Heartbleed. To say otherwise is total i-g-n-o-r-a-n-c-e.

Anyhow, enjoy your lack of transparency and checks/balances. This is just the start of the digital war against us.

 

[Markbnj]

Mark, its clear you know nothing about the internet or computers. Rebooting a server does not do anything that was not done in the first place. In other words, when you turn a computer on it will do the same thing every time. In addition, I have studied this topic extensively and come to the conclusion that this is much ado about nothing.

You're right, I know nothing about the Internet, or computers. And what the hell does "Rebooting a server does not do anything that was not done in the first place" even mean? So in your view there is no difference in the state of memory for a given server if you start it and run it for three years vs. rebooting it every ten minutes? That's ridiculous.

It has already been theorized, and to some extent demonstrated, that the SSL keys are more likely to be in memory contiguous to an area that can be accessed by this bug after openssl initializes at startup. All the Cloudflare guy was saying, and what I was noting, was that rebooting the server may have increased the window of vulnerability for the keys. I'm not sure why you have a problem with this.

 

[Markbnj]

Lets assume your premise is correct, that a lack of buffers increases the likelihood of compromise after reboot.....then why not incorporate a sequence that generates "more and more buffers" that are "created and released" as part of that process?

Am I missing something here? Would Mark care to chime in on this?

Chime in on what? That there are things that could have been done differently to make that memory less likely to be accessible after a reboot? I'm not even sure if that's what you mean, but if so, hardly a revelation. Akamai has already submitted a custom allocator to github that essentially prevents this from happening, and they've been using it internally for quite awhile.

 

[Markbnj]

Too bad he ended up being dead wrong.

There are a lot of allegations flying around, but anyway, I am not going to be the person to underestimate those guys.

 

[Brian Stirling]

NSA says, No, we had no clue:

http://www.huffingtonpost.com/tech/

First of all, the NSA has been caught red handed lying there ass off so lying isn't unexpected from them.

Second, admitting that they knew about this for two years and said nothing, not to mention exploiting it, would put them in a bad place that could have even more heat placed on them with the remote possibility that someone might lose there job because of it. Bottom line ... they have a huge incentive to lie and they're pretty experienced at it.


Brian

 

[Virgorising]

First of all, the NSA has been caught red handed lying there ass off so lying isn't unexpected from them.

Second, admitting that they knew about this for two years and said nothing, not to mention exploiting it, would put them in a bad place that could have even more heat placed on them with the remote possibility that someone might lose there job because of it. Bottom line ... they have a huge incentive to lie and they're pretty experienced at it.


Brian

My compounded stress---beyond the reality of this bug, is, at this juncture, I don't know who or what to believe.

 

[Markbnj]

It's pretty bad, yeah. It's hard to deny that in the wake of the Cloudflare challenge having been met. Btw, Akamai's CTO confirmed on Hacker News that they had gotten keys in roughly the same amount of time in an internal challenge.

So for service providers this blows. A lot of servers will need to be patched and certs are going to have to be rotated out. A ton of money is going to be spent. A lot of consumers will be affected if only because they are going to be told to change all their creds.

But I still think there are some reasons for the ordinary consumer not to freak out. First, openSSH is not affected. This exploit does not give root access to servers, or access to databases, etc. Second, although the potential to acquire ssl keys and decrypt/alter traffic has been proven to exist, and thus we all have to assume people are out there right now in possession of that capability for some major systems, to compromise _your_ personal information using this technique they have to intercept the traffic, which is another whole layer of challenges with its own specific vulnerabilities and protections.

There are some scenarios in which that might not be difficult to do. If you access your online financial accounts from Starbucks you're probably in a vulnerable category. If you do that sort of thing strictly from home via an ISP account the real odds of your information having been intercepted and decrypted are still, imo, extremely low.

I haven't changed any passwords yet in response to this, for two reasons: 1) I haven't had clear communication from financial services providers that their systems are patched, and there is no sense changing passwords until they are; and 2) I access financial accounts only from home, via Comcast, on a wired link, or an AES-2 protected wireless network. As a consumer, I'm personally not that concerned. As an employee of an Internet application developer it's already been a pain in the ass, and I'm sure that is going to continue for some time.

 

[Virgorising]

It's pretty bad, yeah. It's hard to deny that in the wake of the Cloudflare challenge having been met. Btw, Akamai's CTO confirmed on Hacker News that they had gotten keys in roughly the same amount of time in an internal challenge.

So for service providers this blows. A lot of servers will need to be patched and certs are going to have to be rotated out. A ton of money is going to be spent. A lot of consumers will be affected if only because they are going to be told to change all their creds.

But I still think there are some reasons for the ordinary consumer not to freak out. First, openSSH is not affected. This exploit does not give root access to servers, or access to databases, etc. Second, although the potential to acquire ssl keys and decrypt/alter traffic has been proven to exist, and thus we all have to assume people are out there right now in possession of that capability for some major systems, to compromise _your_ personal information using this technique they have to intercept the traffic, which is another whole layer of challenges with its own specific vulnerabilities and protections.

There are some scenarios in which that might not be difficult to do. If you access your online financial accounts from Starbucks you're probably in a vulnerable category. If you do that sort of thing strictly from home via an ISP account the real odds of your information having been intercepted and decrypted are still, imo, extremely low.

I haven't changed any passwords yet in response to this, for two reasons: 1) I haven't had clear communication from financial services providers that their systems are patched, and there is no sense changing passwords until they are; and 2) I access financial accounts only from home, via Comcast, on a wired link, or an AES-2 protected wireless network. As a consumer, I'm personally not that concerned. As an employee of an Internet application developer it's already been a pain in the ass, and I'm sure that is going to continue for some time.

Pls accept my gratitude for this very dense with, I think, accurate data ---offering.

 

[ultimatebob]

If you haven't patched your Internet facing servers running an affected version of OpenSSL by now, you should probably be fired.

It's probably safe to change your passwords now.

 

[spidey07]

If you haven't patched your Internet facing servers running an affected version of OpenSSL by now, you should probably be fired.

It's probably safe to change your passwords now.

My bank still hasn't redone their cert. I'll be staying away.

 

[Virgorising]

My bank still hasn't redone their cert. I'll be staying away.

Pls not to say if U don wanna, but is yours a regional bank or one of the giants?????

 

[FelixDeCat]

()

 

[drebo]

My bank still hasn't redone their cert. I'll be staying away.

Maybe they're not vulnerable?

Cisco uses an older version of OpenSSL that isn't vulnerable...so if they're using Cisco load balancers, they wouldn't be vulnerable and thus would not need to rekey their cert. Also, IIS isn't vulnerable, so there's that, too.

Just assuming that their keys not changing means they're being negligent is pretty dumb on your part.

 

[Red Squirrel]

I'm on night shift at work and kinda want to VPN in my house but I shut down the server till I get around to redoing certs (which is a huge pita). I think I'm going to do that now and get it over with. Have to go find an Open VPN tutorial. I can still SSH in from work so there's that.

Actually, are SSH key pairs also affected by this?

 

[spidey07]

Maybe they're not vulnerable?

Cisco uses an older version of OpenSSL that isn't vulnerable...so if they're using Cisco load balancers, they wouldn't be vulnerable and thus would not need to rekey their cert. Also, IIS isn't vulnerable, so there's that, too.

Just assuming that their keys not changing means they're being negligent is pretty dumb on your part.

Nobody uses Cisco load balancers. If they do they should be fired for stupidity.

 

[PliotronX]

Speaking of Cisco, anyone taking their classes and know what's up with Netacad? What's a certificate revocation?

edit- nvm they must've addressed it in the last few minutes

 

[drebo]

Nobody uses Cisco load balancers. If they do they should be fired for stupidity.

Hah. And yet they exist and people use them.

Either way, lambasting a provider without knowing for certain if they're even vulnerable is kind of stupid. The same would be said of people who wanted to rekey things that weren't vulnerable.

 

[drebo]

I'm on night shift at work and kinda want to VPN in my house but I shut down the server till I get around to redoing certs (which is a huge pita). I think I'm going to do that now and get it over with. Have to go find an Open VPN tutorial. I can still SSH in from work so there's that.

Actually, are SSH key pairs also affected by this?

The bug affects TLS heartbeats by applications that use OpenSSL 1.0.1 thru 1.0.1h.

So, no, it doesn't affect anything that's SSH-based.

 

[bradly1101]

LastPass has a built-in HB bug security check, and tells you which sites in the vault that need updating.