Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Heartbleed OpenSSL Vulnerability: A Technical Remediation

samzenpus posted about 6 months ago | from the protect-ya-neck dept.

Security 239

An anonymous reader writes "Since the announcement malicious actors have been leaking software library data and using one of the several provided PoC codes to attack the massive amount of services available on the internet. One of the more complicated issues is that the OpenSSL patches were not in-line with the upstream of large Linux flavors. We have had a opportunity to review the behavior of the exploit and have come up with the following IDS signatures to be deployed for detection."

Sorry! There are no comments related to the filter you selected.

what? (5, Insightful)

Anonymous Coward | about 6 months ago | (#46709993)

Was this badly translated from another language, or have I been out of system administration too long?

Re:what? (5, Informative)

VortexCortex (1117377) | about 6 months ago | (#46710869)

Was this badly translated from another language, or have I been out of system administration too long?

Allow me to translate from buzz-ard to sysopian:

SSL-Ping Data Exfiltration Exploit: Detection and mitigation even a flaming lamer that can't patch OpenSSL can use

"Since this 0-day vuln was published skiddies have been exploiting it to leak data available to OpenSSL 64KB at a time via running one of the pre-written exploit proof-of-concept sources (as skiddies are wont to do) against a bunch of affected Internet facing services. This SNAFU is particularly FUBAR since all the distros that noobs use are building an ancient OpenSSL ver so they can't even push out a simple patch, obviously. We fingered the exploit in use and have a signature so your punk-buster scripts can detect the crackers and ATH0 before your cipher keys get the five-finger discount."

Re:what? (4, Funny)

TheGratefulNet (143330) | about 6 months ago | (#46710919)

let me run that thru the jive translator:

"well, shit!" ==> "golly!"

Re:what? (1)

Anonymous Coward | about 6 months ago | (#46711047)

Should it bother me that I actually did find this description easier to understand than the original one?

Re:what? (3, Insightful)

I kan Spl (614759) | about 6 months ago | (#46711153)

VortexCortex should be a slashdot editor then. That would be entertaining at least.

Re:what? (2, Informative)

Eunuchswear (210685) | about 6 months ago | (#46711157)

If someone is using an ancient openssl library (0.9.8) they have nothing to worry about. The problem was introduced in 1.0.0

Re:what? (2)

TCM (130219) | about 6 months ago | (#46711813)

Wrong, in 1.0.1.

Re:what? (1)

dave420 (699308) | about 6 months ago | (#46711825)

Two points - 0.9.8 is still under development, and so not ancient, and the problem was introduced in 1.0.1.

Re:what? (1)

Anonymous Coward | about 6 months ago | (#46712397)

0.9.8 is still under development

So is hurd...

Re:what? (1)

ifiwereasculptor (1870574) | about 6 months ago | (#46723651)

Even CentOS is already using 1.0.1, and we're talking about a distribution that is still using kernel 2.6 and Gnome 2 (not even 2.32, but 2.28 still). So yeah, OpenSSL 0.9.8 and 1.0.0 are extremely ancient.

Re:what? (1)

phantomfive (622387) | about 6 months ago | (#46715175)

"Since this 0-day vuln was published skiddies have been exploiting it to leak data available to

It's not a zero-day once the vendor knows about it. It's been four days since it was fixed so it's at least 4-day vuln. Stale already.

I'm going to steal this ASAP! (0)

Anonymous Coward | about 6 months ago | (#46724659)

"SNAFU is particularly FUBAR",

  what poetry!!!!

Spanish verb FUBAR declension (0)

Anonymous Coward | about 6 months ago | (#46724705)

We all know what FUBAR means, and as a standard form Spanish verb it is so handy:

FUBO - I am ...

FUBAS - YOU are ...

FUBA - YOU, sir, are ...

FUBAMOS - WE are ...

FUBAN - THEY are ...

Re:what? (1)

cthulhu11 (842924) | about 6 months ago | (#46726961)

When did we start saying "remediate" instead of "fix"?

Re:what? (0)

Anonymous Coward | about 6 months ago | (#46729573)

+10 Underrated for proper use of "wont".

Re:what? (2)

gweihir (88907) | about 6 months ago | (#46712479)

It is some folks trying to drag IDS back out from the grave. The issue is that generally, IDS does work extremely poorly and causes extreme operations effort (somebody has to look at all the alerts). For this specific thing for once IDS can be used to detect the problem and the whole story revolves about that. Of course the approach is fundamentally flawed: If you patch management is so bad that you cannot fix all affected OpenSSL installations pretty fast, then you are doomed anyways security-wise.

As this is pretty obvious, part of the IDS community is using deceptive and manipulative language to prop-up their meal-ticket and that is what makes the story sound so strange. The other part of the IDS community has realized that IDS as possible currently is a bad idea and has gone back to doing research on the issue. These are the hones ones that do not try to sell you an expensive box that is essentially worthless.

That is not to say, IDS is completely worthless. If you have very specific, well-known signatures, it can help you find _old_ problems that somehow slipped by, but as such it just serves as one small element of a patch-management system.

Fuck Beta (-1)

Anonymous Coward | about 6 months ago | (#46710025)

Burn in hell Dice Inc.
 
Fuck you in the ass.

Thank you for the mess (4, Insightful)

manu0601 (2221348) | about 6 months ago | (#46710037)

We have to thank the security researchers that chose to break the embargo on the news before OpenSSL coordinated with downstream project.

Thank you for the mess, guys!

Re:Thank you for the mess (5, Insightful)

Anonymous Coward | about 6 months ago | (#46710047)

To be fair, nobody knows if this was exploited in the wild or not already - so the "mess" was going to happen anyway (unless you planned to patch your server, assuming your certificate was still good, and not tell any of your users that their passwords may have been exposed in the last couple years).

Re:Thank you for the mess (4, Informative)

ChrisKnight (16039) | about 6 months ago | (#46710063)

Sadly, this is not the case. The evidence is that bad actors had this exploit for months: http://arstechnica.com/securit... [arstechnica.com]

Re:Thank you for the mess (2, Insightful)

Midnight_Falcon (2432802) | about 6 months ago | (#46710091)

I've read your link and can't find any statement that indicates malicious persons had knowledge of this exploit before the announcement.

Re:Thank you for the mess (5, Informative)

Midnight_Falcon (2432802) | about 6 months ago | (#46710101)

Ok, I read the wrong link from up above. This article does say as you claimed, and my above post is nonsense. :)

Re:Thank you for the mess (4, Insightful)

ChrisKnight (16039) | about 6 months ago | (#46710161)

Midnight_Falcon, you are indeed a rare bird. :)

Re:Thank you for the mess (5, Funny)

davester666 (731373) | about 6 months ago | (#46710897)

Not really. Lots of people are wrong on the internets! :-)

Re:Thank you for the mess (0)

Anonymous Coward | about 6 months ago | (#46713683)

I think the 'rare' part is that not a lot of people admit it when they're wrong. Especially on the internets. :)

Re:Thank you for the mess (1)

coolsnowmen (695297) | about 6 months ago | (#46725771)

I think davester666 knew that. But, then again, he is the devil...

fuck beta (0, Flamebait)

CauseBy (3029989) | about 6 months ago | (#46711445)

I'd love to read your original comment but I can't because this beta bullshit doesn't have any parent links. Fuck you, beta!

Re:Thank you for the mess (5, Informative)

ras (84108) | about 6 months ago | (#46710811)

For people who didn't follow the link chain [seacat.mobi] , it has since been updated:

Important update (10th April 2014): Original content of this blog entry stated that one of our SeaCat server detected Heartbleed bug attack prior its actual disclosure. EFF correctly pointed out that there are other tools, that can produce the same pattern in the SeaCat server log (see http://blog.erratasec.com/2014... [erratasec.com] ). I don't have any hard data evidence to support or reject this statement. Since there is a risk that our finding is false positive, I have modified this entry to neutral tone, removing any conclusions. There are real honeypots in the Internet that should provide final evidence when Heartbleed has been broadly exploited for a first time.

Re:Thank you for the mess (2)

Fnord666 (889225) | about 6 months ago | (#46711101)

Sadly, this is not the case. The evidence is that bad actors had this exploit for months: http://arstechnica.com/securit [arstechnica.com] ...

One of the two sites cited as evidence have since taken a step back,

Important update (10th April 2014): Original content of this blog entry stated that one of our SeaCat server detected Heartbleed bug attack prior its actual disclosure. EFF correctly pointed out that there are other tools, that can produce the same pattern in the SeaCat server log (see http://blog.erratasec.com/2014... [erratasec.com] ). I don't have any hard data evidence to support or reject this statement. Since there is a risk that our finding is false positive, I have modified this entry to neutral tone, removing any conclusions. There are real honeypots in the Internet that should provide final evidence when Heartbleed has been broadly exploited for a first time.

Re:Thank you for the mess (3, Insightful)

phantomfive (622387) | about 6 months ago | (#46710575)

Wow, not at all.

News about a vulnerability should never be delayed longer than a workaround is known. That is, if there is a way to defend your servers, you need to let people know about it so they can defend their servers. Attackers don't wait for disclosure.

In this case, there was a simple fix, recompiling OpenSSL with the proper flag and going, so letting people know as soon as possible is the best option. Those who are serious about security don't wait for Ubuntu to update their apt servers.

Re:Thank you for the mess (2)

manu0601 (2221348) | about 6 months ago | (#46710957)

But the problem here is that no downstream distributions (either Linux or *BSD) were notified in advance. As a result there were no patch available for older versions that just had bugfixes backported, and no binary updates.

Re:Thank you for the mess (2, Informative)

phantomfive (622387) | about 6 months ago | (#46711001)

Yes, there are some people who are incapable of compiling their own software who will have to wait until the patch comes through. Those people shouldn't be managing security for a large website (or any website really, in an ideal world).

Re:Thank you for the mess (4, Interesting)

Christian Smith (3497) | about 6 months ago | (#46712177)

Yes, there are some people who are incapable of compiling their own software who will have to wait until the patch comes through. Those people shouldn't be managing security for a large website (or any website really, in an ideal world).

Nonsense. I'd want only vendor supplied fixes applied, unless the vendor is so slow as to be incompetent (but then, why would you be using them?)

Why? Because user applied fixes tend to be forgotten, and if the library isn't managed by the package system (you've uninstalled the package you're overwriting, right?) you might miss subsequent important updates.

An example from a far from fuckwitted user:
http://marc.info/?l=sqlite-use... [marc.info]

Yes, the author of the SQLite library fell pray to this very issue. Let the package manager track packages.

Of course, you could also build binary packages from source, but then that assumes the upstream source packages have been patched, or you're happy to patch the source packages yourself.

Re:Thank you for the mess (0)

Anonymous Coward | about 6 months ago | (#46714873)

Yes, the author of the SQLite library fell pray to this very issue.

That should be "fell prey". Falling into prayer may or may not have happened but is outside the scope of slashdot technobabble.

Slashdot cannot afford to dilute its technobabble jargon with religiosity. At the quantum level the two are immiscible.

And specifically in this case, the original phrase is an insult to predators. Remember, Arnie only got one of those guys. You do not want to piss off any of the others.

Re:Thank you for the mess (0)

Anonymous Coward | about 6 months ago | (#46724533)

>At the quantum level the two are immiscible.

and simultaneously miscible.

Re:Thank you for the mess (0)

phantomfive (622387) | about 6 months ago | (#46715217)

Nonsense. I'd want only vendor supplied fixes applied,

That's fine, but you are either not running a large website, or you are incompetent. You are the kind of person who keeps companies like IBM in business, because you trust vendors for some reason.

Re:Thank you for the mess (1)

Mirar (264502) | about 6 months ago | (#46712475)

It's enormously less work to trust that the upstream and packet system know what needs to be packed and restarted than to keep track on all the patches yourself. How many sysadmins have the _time_ to do source code reviews on _everything_ that needs to go into a complex system? How easy is it to accidentally put in a patch with a deliberate security hole?

(But, apparently the openssl people don't do code reviews either. I'd consider this a good reason to use something else.)

Re:Thank you for the mess (1)

phantomfive (622387) | about 6 months ago | (#46715135)

Some companies roll their own distros. When your site is on fire with a huge vuln, the question isn't, "do I have time for this?" It's, "do I have time for anything else?"

Re:Thank you for the mess (0)

Anonymous Coward | about 6 months ago | (#46722541)

What an overly simplistic view of the world you have. Some of us have very real restrictions on what we can run, how we can make it, and where we can get it. We just can't throw a compiler on a box, download the latest code, compile it and go have a beer.

Re:Thank you for the mess (0)

Anonymous Coward | about 6 months ago | (#46713009)

Well they just experienced the disclosure policy that other software distributors/manufacturers had with other recent OpenSSL related exploits. Why should Linux or *BSD be any different? What's good for the goose is good for the gander.

Re:Thank you for the mess (2)

Pieroxy (222434) | about 6 months ago | (#46711589)

Ubuntu did provide apt patches for all affected versions, including those not supported anymore (12.10 comes to mind). They did it right. If you had configured your security patches to install automatically, it was even transparent. I don't see a problem there.

Re:Thank you for the mess (2, Informative)

Anonymous Coward | about 6 months ago | (#46712473)

I usually agree, but this is a vulnerability where an extreme amount of damage can be avoided by taking down SSL servers as quickly as possible.

Due to the nature of the bug, recorded traffic from up to two years ago can be decrypted if the site doesn't have PFS enabled, which most sites haven't. If you have packet dumps from the coffee shop wifi downstairs, all it takes is a little luck while running the attack on a couple of big mail providers to get the servers' private keys: Then you can decrypt everybody's mail sessions, web shopping and online banking, including user names, passwords and content, from up to two years ago! The exact nature of the bug should not have been revealed before telling everybody who's running OpenSSL 1.0.1 onward to shut down the server.

Nobody should have kept a vulnerable SSL server running for even just a minute after the announcement. The right reaction would have been to halt the server immediately upon being told of the bug. Patching as quickly as possible is not quick enough.

IDS patterns are pointless now: The attack is already being integrated into end user software to alert users of vulnerable sites. The servers will be hammered with this attack from thousands of IPs and the users who run these "attacks" won't even know they're doing it.

I think most people have yet to realize the magnitude of this fuckup.

Re:Thank you for the mess (1)

Ash Vince (602485) | about 6 months ago | (#46713403)

In this case, there was a simple fix, recompiling OpenSSL with the proper flag and going, so letting people know as soon as possible is the best option. Those who are serious about security don't wait for Ubuntu to update their apt servers.

Recompiling something from source is often a complete no-no, not because the sysadmin is unable to, but because he his forbidden from doing so by his corporate overlords. It is trusted binaries (via checksum) from the likes of RedHat or nothing.

Re:Thank you for the mess (1)

phantomfive (622387) | about 6 months ago | (#46715089)

That sounds like a reasonable corporate strategy.

Download new OpenSSL, not just recompile (1)

billstewart (78916) | about 6 months ago | (#46720753)

No, you actually have to fix the code to add bounds checking, or download a new version of OpenSSL (which probably gets you other fixes as well, unless you were already running the latest version.)

Recompiling OpenSSL with the proper flag isn't enough to do the job - there are people who've done that and had problems keeping OpenSSL stable on their platforms, and more importantly, that still doesn't stop the Heartbleed attack from causing trouble. You need to get the code not to try to fetch memory beyond the appropriate object's array bounds, though OpenSSL should also default to using malloc()/free() instead of rolling its own badly.

Re:Download new OpenSSL, not just recompile (1)

phantomfive (622387) | about 6 months ago | (#46721109)

You just need to use -DNO_SECURITY_FLAWS. Problem solved.

Re:Thank you for the mess (1)

Kittenman (971447) | about 6 months ago | (#46710851)

Who was it who said "bad news travels 'round the world while the truth is still putting on it's laces"?

Churchill, I suspect ...

Re:Thank you for the mess (3, Informative)

QRDeNameland (873957) | about 6 months ago | (#46711355)

Mark Twain, actually. [wikiquote.org]

Re:Thank you for the mess (1)

Opyros (1153335) | about 6 months ago | (#46716571)

Charles Haddon Spurgeon, according to TwainQuotes.com [twainquotes.com] (scroll down to the bottom of the page).

Incompetent or deliberate? (1)

Anonymous Coward | about 6 months ago | (#46711697)

I looked at the code. The design is AMAZINGLY bad. I think it's probably a deliberately bad design that was created to hide the exploit. Probably the feature itself was designed for the exploit, but the exploit was kept out of the first version of it so that the code wouldn't be under scrutiny when the exploit was added.

I read that that part of the protocol (the ping - probably a custom add-on for open ssl) was designed by the same guy who implemented it.

It's a ping which:

1) is an unnecessary feature in itself.

2) giving it a payload is also unnecessary

3) allowing that payload to be longer than necessary to stamp, number and keep track of packets is malicious. 1 byte would be enough to be useful (if hard to use) 8 bytes should be more than enough for anyone! 65530 some odd bytes max? WTF? Who in their right mind allows that in a ping? It's designed as AT LEAST a secret side channel!

4)giving that payload a "size" field that's redundant (since the packet HAS a size) is malicious and allowed the programmer to trust a bullshit size field instead of using the actual size. And there is the anatomy of snuck in exploit - make a redundant field which should never be trusted or used - then pretend to trust it. God, no programmer in their right mind!

If anyone is in charge of openssl they should exclude the guy who wrote that and rewrite everything he's touched.

Or, Openssl should be considered trash and replaced in every package.

I found the reason they allowed huge pings (0)

Anonymous Coward | about 6 months ago | (#46712353)

http://en.wikipedia.org/wiki/Path_MTU_Discovery

Path MTU Discovery.
The idea is that, for speed and reliability purposes, you find the largest packet size that won't fragment in your path by sending larger and larger packets with "don't fragment" on...

Re:Incompetent or deliberate? (0)

Anonymous Coward | about 6 months ago | (#46715055)

Other than the NSA, who would have the resources to pull off this caper? What you are describing would require expertise in highly technical coding (not hard to find), expertise in human factor exploitation to slip the crap into place (again, not hard to find but generally incompatible with technical expertise), a budget large enough to manage the patience period from submission of first version to submission of version with the exploit (rather rare in the field), and a willingness to forego picking the low hanging fruit that would have given away the game long before now (only governments generally exhibit this behavior).

If this was not some kind of coding error, and parent post makes a strong argument that it probably was not, then the NSA, China, Iran, and Israel are all likely suspects.

Oh, and of course the Koch brothers. Who might have done it for the good of the Order.

posted anonymously as I have invested mod points in this thread

Is OpenVPN affected? (1)

manu0601 (2221348) | about 6 months ago | (#46710053)

Someone knows if OpenVPN is affected? The tests do not work on it since it uses TLS in an unusual way.

Re:Is OpenVPN affected? (4, Informative)

ChrisKnight (16039) | about 6 months ago | (#46710151)

Some versions are. The OpenVPN appliance I was running was affected, and there were no updates for it this morning so I had to kill it.

https://security.stackexchange... [stackexchange.com]

I read somewhere that there is a TLS flag you can use in the config to disable the affected code, but for the life of me I can't find it for this post. :(

Re:Is OpenVPN affected? (4, Informative)

Ingenium13 (162116) | about 6 months ago | (#46710249)

I think if you had enabled the tls-auth option it prevents the attack.

Re:Is OpenVPN affected? (0)

Anonymous Coward | about 6 months ago | (#46710997)

Only from users who don't have the key. Insiders can still use it. That's a massive improvement though.

Re:Is OpenVPN affected? (1)

Anonymous Coward | about 6 months ago | (#46711491)

Correct. A preshared key is needed to even start an SSL conversation.

Re:Is OpenVPN affected? (0)

Anonymous Coward | about 6 months ago | (#46710673)

I believe you are refering to this:

~ taken from: http://heartbleed.com/ ...
How can OpenSSL be fixed?

Even though the actual code fix may appear trivial, OpenSSL team is the expert in fixing it properly so latest fixed version 1.0.1g or newer should be used. If this is not possible software developers can recompile OpenSSL with the handshake removed from the code by compile time option -DOPENSSL_NO_HEARTBEATS ...

But only apply if you actualy recompile the package.

Re:Is OpenVPN affected? (0)

Anonymous Coward | about 6 months ago | (#46731317)

-DOPENSSL_NO_HEARTBEATS

Re:Is OpenVPN affected? (1)

wytcld (179112) | about 6 months ago | (#46712693)

See this notice [openvpn.net] - the answer is yes, if affected versions of openssl are on the system.

Should've taken your heartworm pills. (-1)

Anonymous Coward | about 6 months ago | (#46710067)

nt

IDS != Remedy (2)

AcerbusNoir (1257586) | about 6 months ago | (#46710071)

An IDS provides the means to detect malicious patterns in traffic. It is by no mean a remedy.

Re:IDS != Remedy (0)

Anonymous Coward | about 6 months ago | (#46710329)

If this logic were true, we'd already have several "Cancer Remedies".

Re:IDS != Remedy (1)

viperidaenz (2515578) | about 6 months ago | (#46710501)

It can help. If you detect and block the traffic, how is the exploit performed?

Re:IDS != Remedy (1)

Anonymous Coward | about 6 months ago | (#46710803)

Many IDSs run async of the connections since real-time monitoring could severely limit performance. An IDS will probably detect the issue after it has already happened. "Intrusion Detection System" is not the same as a real-time firewall.

What version does OpenBSD use? (1)

sconeu (64226) | about 6 months ago | (#46710075)

If it's using one of the affected versions, how did it get past the famed OpenBSD audits?

Re:What version does OpenBSD use? (1)

Anonymous Coward | about 6 months ago | (#46710129)

Apparently like this:

http://thread.gmane.org/gmane.... [gmane.org]

Having their own malloc() replacement that avoids the host OS "protections"

Re:What version does OpenBSD use? (5, Interesting)

Anonymous Coward | about 6 months ago | (#46710439)

That's good post. I'm going to blatantly copypaste it because Theo gets to the crux of why Openssl is terrible:

From: Theo de Raadt cvs.openbsd.org>
Subject: Re: FYA: http://heartbleed.com/ [heartbleed.com]
Newsgroups: gmane.os.openbsd.misc
Date: 2014-04-08 19:40:56 GMT (1 day, 6 hours and 15 minutes ago)

> On Tue, Apr 08, 2014 at 15:09, Mike Small wrote:
> > nobody gmail.com> writes:
> >
> >> "read overrun, so ASLR won't save you"
> >
> > What if malloc's "G" option were turned on? You know, assuming the
> > subset of the worlds' programs you use is good enough to run with that.
>
> No. OpenSSL has exploit mitigation countermeasures to make sure it's
> exploitable.

What Ted is saying may sound like a joke...

So years ago we added exploit mitigations counter measures to libc
malloc and mmap, so that a variety of bugs can be exposed. Such
memory accesses will cause an immediate crash, or even a core dump,
then the bug can be analyed, and fixed forever.

Some other debugging toolkits get them too. To a large extent these
come with almost no performance cost.

But around that time OpenSSL adds a wrapper around malloc & free so
that the library will cache memory on it's own, and not free it to the
protective malloc.

You can find the comment in their sources ...

#ifndef OPENSSL_NO_BUF_FREELISTS /* On some platforms, malloc() performance is bad enough that you can't just

OH, because SOME platforms have slow performance, it means even if you
build protective technology into malloc() and free(), it will be
ineffective. On ALL PLATFORMS, because that option is the default,
and Ted's tests show you can't turn it off because they haven't tested
without it in ages.

So then a bug shows up which leaks the content of memory mishandled by
that layer. If the memoory had been properly returned via free, it
would likely have been handed to munmap, and triggered a daemon crash
instead of leaking your keys.

OpenSSL is not developed by a responsible team.

Re:What version does OpenBSD use? (0)

Anonymous Coward | about 6 months ago | (#46712259)

Theo is not a network programmer, is he?

It shows because memory pools, caching is a really.. I mean really old technique...

Re:What version does OpenBSD use? (1)

bdrasin (17319) | about 6 months ago | (#46727525)

Two things every programmer should know (yes, this applies to you):

1) You are not smart enough to write your own crypto, so don't
2) You are not smart enough to write your own memory allocation, so don't

Re:What version does OpenBSD use? (1)

ArchieBunker (132337) | about 6 months ago | (#46710135)

Theo claims OpenBSD is unaffected. http://undeadly.org/cgi?action... [undeadly.org]

Re:What version does OpenBSD use? (5, Informative)

Phs2501 (559902) | about 6 months ago | (#46710167)

Theo claims OpenBSD is unaffected. http://undeadly.org/cgi?action... [undeadly.org]

Theo claims OpenSSH is unaffected, because it isn't. OpenSSL, even on OpenBSD, is quite affected.

Re:What version does OpenBSD use? (1)

rubycodez (864176) | about 6 months ago | (#46710795)

or is if you didn't apply patch they put out the same day

Re:What version does OpenBSD use? (0)

Anonymous Coward | about 6 months ago | (#46716695)

Theo claims OpenBSD is unaffected. http://undeadly.org/cgi?action... [undeadly.org]

Theo claims OpenSSH is unaffected, because it isn't. OpenSSL, even on OpenBSD, is quite affected.

OpenSSH uses OpenSSL. If it uses an unpatched version of OpenSSL than it very well could be affected.

That said, it also implements the SSH protocol which may not make use of the TLS functionality in OpenSSL, which is probably what is being noted.

Re:What version does OpenBSD use? (0)

Anonymous Coward | about 6 months ago | (#46720539)

the SSH protocol which may not make use of the TLS functionality in OpenSSL

It doesn't, that's why it's not affected.

Re:What version does OpenBSD use? (1)

Anonymuous Coward (1185377) | about 6 months ago | (#46714751)

They simply didn't audited it at all.

They just included it as delivered by the OpenSSL people (BTW, OpenSSL is a different project, no relation to OpenBSD).

A simple code changes review would have caught such an obvious bug (trusting without checking a buffer length parameter received over the network).

As to their memory randomization thing and how OpenSSL worked around that by wrapping malloc(), that's a red herring; if you're able to read the whole process memory by 64kb, there's no problem to follow all pointers in the manner of a garbage collector, or simply mine it following known patterns.

it's all over (1)

turkeydance (1266624) | about 6 months ago | (#46710085)

NSA, heartbleed, whatever. you'll tell your grandchildren about "back in the day" internet.

Re:it's all over (2)

VortexCortex (1117377) | about 6 months ago | (#46710901)

Back in my day this wouldn't have been an issue since we ran a host of different custom interfaces and clients. We had to organize our own cross country backhaul via overlapping local calling networks, and orchestrated email routing networks using outdials. Probably only hackers used clients with encrypted links for their BBSs.

I don't know what you're talking about with that fed-speak. I never heard of any crazy lossy crap like duct-taping payphones together neither, but there may have been a few railroad tracks used as a transmission lines, or party-numbers as hubs to spook the ghost-busters at their own game, but those were just urban legends, of course.

Re:it's all over (1)

Jeremi (14640) | about 6 months ago | (#46711267)

NSA, heartbleed, whatever. you'll tell your grandchildren about "back in the day" internet

What in particular do you think will be different about my grandchildrens' Internet?

Re:it's all over (2)

oreaq (817314) | about 6 months ago | (#46711765)

It will be indistinguishable from today's cable TV.

Re:it's all over (1)

SuricouRaven (1897204) | about 6 months ago | (#46711995)

They'll just call it the 'Googlebook.'

Mountain out of a molehill (0)

dreamchaser (49529) | about 6 months ago | (#46710087)

It's amusing how much talk is going on about this. Patching the vulnerability is trivial. All of the major IPS and IDS products out there already have signatures published to remediate it for organizations who for whatever reason can't patch. This is getting silly.

Re:Mountain out of a molehill (5, Insightful)

NiteMair (309303) | about 6 months ago | (#46710149)

Except now pretty much every affected machine needs to have its SSL certificates and private keys revoked and trashed, and new keys/certificates issued.

In the meantime, thousands (if not millions) of sites leaked sensitive data to anyone who wanted to snoop on it.

Yeah, no big deal, none at all...no repercussions will come of this.

Re:Mountain out of a molehill (0)

dreamchaser (49529) | about 6 months ago | (#46710215)

I didn't say it wasn't a pain in the ass. It's just easy to fix.

Re:Mountain out of a molehill (1)

Anonymous Coward | about 6 months ago | (#46710259)

I didn't say it wasn't a pain in the ass. It's just easy to fix.

Let me guess. You must be in management.

Re:Mountain out of a molehill (2)

dreamchaser (49529) | about 6 months ago | (#46710323)

Nope. I am a senior engineer for an IT security firm. I fix this shit for a living, thank you.

Re:Mountain out of a molehill (1)

Anonymous Coward | about 6 months ago | (#46710373)

Then that is truly sad that you have no understanding just how disastrous from a security standpoint this is. once data is leaked it can't be unleaked. it is a fucking mountain not a molehill.

Re:Mountain out of a molehill (4, Insightful)

dreamchaser (49529) | about 6 months ago | (#46710407)

I think you completely missed my point. The hand wringing is useless. Fix it, mitigate it, and try to move on. Any damage that has been done is one. All that cane be done now is to patch and mitigate. All the wrangling going on on the 'net is amusing. The past can't be changed. We can learn from it and move on. There are plenty of ways to stop the bleeding. People are acting like the sky is falling. It's truly sad that you're one of them.

Re:Mountain out of a molehill (1)

dreamchaser (49529) | about 6 months ago | (#46710417)

WOW, bad spelling and typos. I chalk that up to the beers I am drinking :)

Seriously though, it's not as big a deal as it's being made out to be. Yes it caused a security scramble, and rightly so. No, the sky is not falling.

Re:Mountain out of a molehill (0)

Anonymous Coward | about 6 months ago | (#46710465)

Please tell us the firm you work for. I want to be sure my company never contracts it.

Re:Mountain out of a molehill (1)

decaffeinated (70626) | about 6 months ago | (#46711399)

Me too. I also want to know what company Dreamchaser works for. Dreamchaser's infuriating condescension is why so many people despise picking up the phone and calling the IT dept. for help ("Yeah, sure, I'll call the helpless desk and they'll fix my problem. Ya, you betcha."

Or maybe Dreamchaser does all his banking with paper checks.

Re:Mountain out of a molehill (1)

Pieroxy (222434) | about 6 months ago | (#46711641)

I honestly don't know what you're talking about. There's been a vulnerability disclosed. Fixing it is trivial. Regenerating your keys is (or should be) trivial. End of story.

Yes, this vulnerability is scary, and even more scary thing is that there are probably other vulns that bad in the wild, and most likely plenty of them. But this is over.

When I first saw Stuxnet and the extent of this shit, I lost all confidence in online data, for good. Heck, Stuxnet even infiltrated an offline network. Heartbleed is shit compared to this. The point is that everything that is online can be breached. End of story. We closed one door yesterday, I'm sure there are still 100 others open. So you see? No big deal really.

Re:Mountain out of a molehill (0)

Anonymous Coward | about 6 months ago | (#46710925)

This may have been in the wild for quite awhile before disclosure. You must be terrible as a security engineer.

Re:Mountain out of a molehill (0)

Anonymous Coward | about 6 months ago | (#46710521)

The fact that one can't change that something has happened doesn't alter the magnitude of it.

"whelp, all the data that's spent any time in ram over the past 2 years or so is potentially compromised.. but it's no biggy, we've installed the patch!"

My gut tells me this hasn't been exploited much in the wild, but you can't call something that's basically a remote memory dump impacting over half the internet for the last 2 years a molehill..

Re:Mountain out of a molehill (5, Informative)

Anonymous Coward | about 6 months ago | (#46710863)

I work for a large financial organization. While fixing the hole itself was easy- having to tell a bunch (I can't even legally give you a ballpark, but its a lot) of customers to change their passwords (or forcing them to change) is very bad PR. Plus we don't know if any financial data was accessed. The data could literally bankrupt very large companies or my own company. This is no small problem!

Re:Mountain out of a molehill (1)

Pieroxy (222434) | about 6 months ago | (#46711651)

If you learned anything from Stuxnet, you would no that no data is secure whenever it's online. No data at all. Stuxnet had zero-days for all OSes that noone knew about before it was discovered, and not just one of them. Chances are your system is already compromised and nobody even knows about it. And if it is not, it could be at any time. We closed a door with Heartbleed, but there are countless doors still open, just waiting to be discovered.

Re:Mountain out of a molehill (0)

Anonymous Coward | about 6 months ago | (#46711791)

I'm pretty sure you missed the point entirely

"It's not easy to fix leaked data."

This is entirely true, you can't revoke leaked sensitive data exposed through the exploit, you can tell us not to dwell on the past as much as you like, it doesn't make this any less impossible to fix, the data has leaked, that data could cause serious damage somewhere down the line.

Nope. I am a senior engineer for an IT security firm. I fix this shit for a living, thank you.

This is the bit where you went full retard, and frankly the idea of you being anything close to what you claim to be worries me.

Of course it's reasonable to assume that the guy who claims to be paid to "fix this shit" is probably some clueless kiddy and doesn't warrant picking apart like this, but hey, i'm bored.

Re:Mountain out of a molehill (1)

SuricouRaven (1897204) | about 6 months ago | (#46712005)

It's a bit more than that. There's no way to be sure data wasn't already leaked before you got the patching in - you know there will be hopefuls scanning the entire internet for vulnerable hosts and grabbing everything they can. That means you have to assume your SSL cert is compromised, which means generating a new one and getting it signed. And anything else the compromised process might have in memory space - SSH auth keys, user password database, that sort of thing. It's just annoying. There's nothing really difficult, but if you've got a few servers it could take up a significant amount of time re-securing everything.

Re:Mountain out of a molehill (4, Informative)

Anrego (830717) | about 6 months ago | (#46710335)

It's not easy to fix leaked data.

You can revoke keys, change passwords, and patch the software, but you can't revoke the data that was already sent with them (and can now be decoded) no more than you can you revoke the bits of data that could have been stolen.

Re:Mountain out of a molehill (2)

Dagger2 (1177377) | about 6 months ago | (#46712453)

You can't unsend that data, but perfect forward secrecy [wikipedia.org] means that old data can't be decrypted even if the SSL key leaks, and new data can only be decrypted with an active MITM.

...if only people would actually turn it on.

Of course, this particular vulnerability is even worse than just exposure of on-wire traffic. It also exposed potentially anything in memory for the past two years, including the things you didn't even want to send to other people -- and it exposed them to anybody on the internet, not just people in a position to capture all your traffic. Patching your copy of OpenSSL is certainly trivial, but dealing with all the rest of the fallout from this is most definitely not.

Re:Mountain out of a molehill (1)

Bengie (1121981) | about 6 months ago | (#46712575)

Not "easy" to fix, but "simple" to fix. Digging a lake with a spoon is simple, but I wouldn't say easy.

Re:Mountain out of a molehill (5, Interesting)

kiite (1700846) | about 6 months ago | (#46710659)

It's worse than that. Most browsers don't check certificate revocation lists [spiderlabs.com] , and the certificate authority might not have a CRL infrastructure in place that can support the number of revoked certs generated by this incident.

Granted, they could take the money they receive from all the reissued certificates and use it to build such an infrastructure, but they probably won't.

Web-SSL was already a broken system [theregister.co.uk] . Now that it's been cracked open even wider, maybe we can throw it out and implement something better.

Oh, who am i kidding? We'll just pretend everything's okay again after most people have patched the hole.

Re:Mountain out of a molehill (1)

phantomfive (622387) | about 6 months ago | (#46711065)

Oh, who am i kidding? We'll just pretend everything's okay again after most people have patched the hole.

Don't worry, there are plenty of other holes.

Re:Mountain out of a molehill (1)

colfer (619105) | about 6 months ago | (#46710959)

You were better off using non-SSL, unless you were on wireless or something easily snooped. I'm not aware http:80 [80] servers have a little query that gets you memory dumps. Do I misunderstand?

Re:Mountain out of a molehill (0)

Anonymous Coward | about 6 months ago | (#46712945)

Are there really millions of sites using apache and openSSL? and of these sites the heartbeat option? it is being blown out of proportion.

Re:Mountain out of a molehill (0)

Anonymous Coward | about 6 months ago | (#46710179)

Sure, patching it NOW is trivial. The question is, how long have malicious actors known about this and exploited it?

If someone used it to pull a bunch of login credentials and your SSL certificate's private keys two months ago, patching isn't sufficient to solve the problem.

Re:Mountain out of a molehill (1)

dreamchaser (49529) | about 6 months ago | (#46710221)

That is why part of the remediation process is new certs. I didn't say it wasn't a pain in the ass, but it's trivial with regards to the amount of work involved.

Re:Mountain out of a molehill (4, Informative)

bloodhawk (813939) | about 6 months ago | (#46710383)

trivial? excellent then you can show us how to trivially identify what data has been leaked/exposed and what needs to be reported to the various authorities that require reports on exposed privacy data.

Re:Mountain out of a molehill (1)

grahamsaa (1287732) | about 6 months ago | (#46710867)

What if you work for an organization that has hundreds or thousands of users who connect to a SSL VPN? Re-issuing a single certificate isn't so bad, but re-issuing many certs (and working with end users to roll them out) sounds like a nightmare. Many businesses are also responsible for more than one website, and / or are heavily regulated. Just getting lots of users to change their passwords is bad enough, but if you have to tell them that their credit card number or medical information may have been compromised, possibly provide credit monitoring services for awhile, etc., is ABSOLUTELY a lot of work for a department or an organization.

Re:Mountain out of a molehill (0)

Anonymous Coward | about 6 months ago | (#46711757)

and how is a certificate replacement going to remedy that backdoor they installed? or how about the system audits of what data has been compromised? or how about the thousands of remote users that have to come in to get their machines issued with new certs for VPN's. You obviously don't work in IT let alone security, if you do I pity your poor employers for you to have such a tenuous grasp of the implications behind this vulnerability.

Re:Mountain out of a molehill (0)

Anonymous Coward | about 6 months ago | (#46710571)

You gotta be kidding me man.

Patching most vulnerabilities is trivial. Fixing the damage they caused is what makes something a big deal.

The scope of this is as far as I know unprecedented. The amount of data that's potentially been compromised is ridiculous, and we really have no way of knowing whether something was compromised or not. We're not even just talking passwords and CC numbers that can be changed... medical records, private emails, trade secrets.. it's not hard to imagine a lot of bad scenarios.

Not exactly a molehill. (2)

kiite (1700846) | about 6 months ago | (#46710593)

There are many organizations that not only can't patch, do not know how to patch, or simply haven't completed patching, but also don't _have_ an IPS or IDS in place. In fact, even if a company is in a position (and has the know-how) to install one, using either one of these options may come with what is perceived as an unacceptable performance impact.

I managed to write an exploit for this issue within about 30 minutes. The bug is almost trivial to exploit. In my meager tests, i gathered usernames, passwords, session cookies, and oauth2 client tokens from an unrelated location on the internet. So, yes, i'd say the issue leans a bit closer to mountain than molehill.

That said, the fix is also trivial, and the fact that several distributions still don't have updated packages is downright embarrassing.

No, it's a mountain. (0)

Anonymous Coward | about 6 months ago | (#46711745)

Every secret ssl key is vulnerable. A lot of sites won't buy new ones till their current ones expire. How long does that take, a year, a few years?

And until then, you don't necessarily have any security, even if you change your passwords. And if every system on the internet is vulnerable for the next six months, then nothing will be trustably secure for decades to come. Everything will have possible back doors, your old and new passwords possibly known etc. etc. etc.

Situation is a Shambles (5, Insightful)

ObsessiveMathsFreak (773371) | about 6 months ago | (#46710095)

I'm running Linux Mint Olivia -- the next to current version -- an no openssl patch is yet available as of this afternoon. I image there are quite a few similar distros. Since I have actual work to do, and can't risk wasting two hours on a potentially borked upgrade, I'm stuck to trying not to use programs affected by the exploit for the duration.

While something tells me this exploit is somewhat overblown, what really ticks me off is that this is all the result of delegating memory management to C pointers and basically mmap. As far as I'm concerned, in this day and age, that amounts to spaghetti code and I can't say it endears me to the reliability of openssl.

Please, we need SSL to be secure, not fast. Just use a less efficient method to make things more secure.

Re:Situation is a Shambles (-1)

Anonymous Coward | about 6 months ago | (#46710153)

delegating memory management to C pointers and basically mmap

And this, ladies and gents, is why unmanaged languages need to die. It's been proven time after time after nauseating time that programmers CANNOT create robust code in 70's style "glorified assembly" languages.

Really, it's time to stop. There are better ways now. When the older generation of C/C++ using programmers finally dies off, then maybe we can finally move on. But for now, there's too many people who don't want to learn new things, and the result is exactly.... Heartbleed.

Attempts to defend bad programming practices by those people who don't want to change in 3, 2, 1, ...

Re:Situation is a Shambles (1)

Anonymous Coward | about 6 months ago | (#46710191)

I agree 100%, since there have never been bugs in languages like Java.

Re:Situation is a Shambles (4, Funny)

The Snowman (116231) | about 6 months ago | (#46710251)

I agree 100%, since there have never been bugs in languages like Java.

Also, managed languages like Java and .NET are written in other managed languages running bytecode, making them extra secure. At no time do any of these languages use libraries or environments written in lower level languages such as C++, C, or assembler. So to the GP's credit, programmers who know those languages are okay to die off since we do not need them anyway.

Re:Situation is a Shambles (1)

viperidaenz (2515578) | about 6 months ago | (#46710569)

To be fair, not many of the security bugs in Java are caused by Java code. Off the top of my head the only recent one was an early version of Java 7 that allowed untrusted code to bypass the security manager.

Most of it comes from the Java Browser plugin, which is written in C++, and why you should never run Java code in a browser.

Re:Situation is a Shambles (2, Informative)

Anonymous Coward | about 6 months ago | (#46710217)

You're amazingly wrong.

http://article.gmane.org/gmane.os.openbsd.misc/211963

This has nothing to do with unmanaged languages. It has to do with somebody actively sidestepping security devices that are already in place because they don't grok the way the world works outside of their test bench.

What do you think Python was written in? Here's a hint, it wasn't another managed language.

Re:Situation is a Shambles (2)

viperidaenz (2515578) | about 6 months ago | (#46710547)

Unmanaged languages have their place.
C was designed to write operating systems.
Java and the like are designed to write applications.

Unmanaged languages are used to write the manages language virtual machines. You can't get away from that.

JVM's are written in C and C++, the CLR is the same. Which managed language do you suggest to use that was not built with C?

Re:Situation is a Shambles (0)

Anonymous Coward | about 6 months ago | (#46710705)

It not about "Unmanaged" vs managed. Its about memory safety. You are not running untrusted code, you don't need to stick in is some managed secure VM. In-fact its the exact opposite, you are trusting the code with your private data + network access. I've written enough "Managed" C++ to know thats not a solution to this problem.

What matters here are things like memory safety. Go or Rust provide good options there despite being native compiled languages. There are lots of such options.

Also there are many language implementations not based in C. Look at PyPy (Its python in python). There are plenty of lisp implementations in lisp I'm sure, and upcoming Go compiler in Go. Those are just some self hosting options. I'm sure you can find lots of compilers and interpreters written in javascript, or python, or lisp.

Also, to get technical here, you don't build a language with C, you build an implementation with it. Just because CPython was written in C does not mean Python is written in C (There are other versions written in other languages, such as PyPy). There is no real need to write in a language without memory safety these days other than interoperability. I'm looking forward to seeing how Rust performs in that respect.

Re:Situation is a Shambles (3, Insightful)

Jeremi (14640) | about 6 months ago | (#46711243)

JVM's are written in C and C++, the CLR is the same. Which managed language do you suggest to use that was not built with C?

The point isn't to eliminate C code entirely, but to minimize the number of lines of C code that are executed.

If (statistically speaking) there will are likely to be N memory-error bugs per million lines of C code, then the number of memory-error bugs in a managed language will be proportional to the size of the interpreter, rather than proportional to the size of the program as a whole.

Add to that the fact that interpreters are generally written by expert programmers, and then they receive lots and lots of testing and debugging, and then (hopefully) become mature/stable shortly thereafter; whereas application code is often written by mediocre programmers and often receives only minimal testing and debugging.

Conclusion: Even if the underlying interpreter is written in C, using a managed language for security-critical applications is still a big win.

Re:Situation is a Shambles (3, Interesting)

unrtst (777550) | about 6 months ago | (#46716237)

Add to that the fact that interpreters are generally written by expert programmers, and then they receive lots and lots of testing and debugging, and then (hopefully) become mature/stable shortly thereafter; whereas application code is often written by mediocre programmers and often receives only minimal testing and debugging.

I'd wager that most of those writing/maintaining OpenSSL are not only expert programmers, but, overall, are more security concious than the authors/maintainers of interpreters. You point would be completely valid if the topic was some builitin board / wiki / chat program / etc. Sadly, that's not the case at hand.

Re:Situation is a Shambles (0)

Anonymous Coward | about 6 months ago | (#46710965)

Really, it's time to stop. There are better ways now. When the older generation of C/C++ using programmers finally dies off, then maybe we can finally move on. But for now, there's too many people who don't want to learn new things, and the result is exactly.

The more important die off is the older generation c/c++ era MANAGEMENT. Though they themselves seem immortal, die off of their CULTURE is the pre-req for your proposed move on.

The problem that causes this kind of stuff isn't related to code. It's related to politics which governs process which governs code - same as it ever was.

Stop giving politics an out by treating crap like this as if it's anything different than a predicable result just because it was done on a computer... unless you want to patent the 'done on a computer' aspect.

Re:Situation is a Shambles (1)

Bengie (1121981) | about 6 months ago | (#46712671)

And this, ladies and gents, is why unmanaged languages need to die.

I know the feeling. Every time I read about a SQL injection attack, I think, many, they need to get rid of relational databases and every time I read about someone's computer getting hacked, I think, man, they should get rid of the Internet.

Beta Sucks (0)

Anonymous Coward | about 6 months ago | (#46710163)

Uh, Olivia's been out of support for a couple of months, hasn't it?

Re:Beta Sucks (1)

ObsessiveMathsFreak (773371) | about 6 months ago | (#46713713)

The latest version of Mint is Petra (16). Olivia is 15. You'd think criticaly security updates would be backported at least.

Re:Situation is a Shambles (0)

Anonymous Coward | about 6 months ago | (#46710165)

Easier: Unit test before releasing things.

Coding Style versus Language (5, Insightful)

nanolith (58246) | about 6 months ago | (#46710175)

There is well written C, and there is poorly written C. I've been through the bowels of OpenSSL, and there are parts of it that frighten me. Ninety percent of the issues in OpenSSL could be solved by adopting a modern coding style and using better static analysis. While static analysis tools can't find vulnerabilities, they can root out code smell that hides vulnerabilities. If, for instance, I followed the advice of two of the quality commercial static analyzers that I ran against the OpenSSL code base, I would have been forced to refactor the code in such a way that this bug would have either been obvious to anyone casually reviewing it, if the refactor did not eliminate the bug all together.

C and C++ are not necessarily the problem. It's true that higher level languages solve this particular kind of vulnerability, but they are not safe from other vulnerabilities. To solve problems like these, we need better coding style in critical open source projects.

Re:Coding Style versus Language (0)

Anonymous Coward | about 6 months ago | (#46710267)

Indeed. C written a couple decades ago looks a bit different than it does now.

Re:Coding Style versus Language (0)

Anonymous Coward | about 6 months ago | (#46710305)

http://article.gmane.org/gmane... [gmane.org]

from the link,

> On Tue, Apr 08, 2014 at 15:09, Mike Small wrote:
> > nobody gmail.com> writes:
> >
> >> "read overrun, so ASLR won't save you"
> >
> > What if malloc's "G" option were turned on? You know, assuming the
> > subset of the worlds' programs you use is good enough to run with that.
>
> No. OpenSSL has exploit mitigation countermeasures to make sure it's
> exploitable.

What Ted is saying may sound like a joke...

So years ago we added exploit mitigations counter measures to libc
malloc and mmap, so that a variety of bugs can be exposed. Such
memory accesses will cause an immediate crash, or even a core dump,
then the bug can be analyed, and fixed forever.

Some other debugging toolkits get them too. To a large extent these
come with almost no performance cost.

But around that time OpenSSL adds a wrapper around malloc & free so
that the library will cache memory on it's own, and not free it to the
protective malloc.

You can find the comment in their sources ...

#ifndef OPENSSL_NO_BUF_FREELISTS /* On some platforms, malloc() performance is bad enough that you can't just

OH, because SOME platforms have slow performance, it means even if you
build protective technology into malloc() and free(), it will be
ineffective. On ALL PLATFORMS, because that option is the default,
and Ted's tests show you can't turn it off because they haven't tested
without it in ages.

So then a bug shows up which leaks the content of memory mishandled by
that layer. If the memoory had been properly returned via free, it
would likely have been handed to munmap, and triggered a daemon crash
instead of leaking your keys.

OpenSSL is not developed by a responsible team.

Re:Coding Style versus Language (1)

nanolith (58246) | about 6 months ago | (#46710411)

Theo de Raadt is correct, if not a bit abrasive in his assessment of the situation.

Two years of dedicated work: writing proper unit tests, refactoring code, and refreshing this library would do wonders for this project.

Integer Overflow on the patch?! (0)

Anonymous Coward | about 6 months ago | (#46710791)

unsigned int payload;
+ unsigned int padding = 16; /* Use minimum padding */
+
+- /* Read type and payload length first */
+- hbtype = *p++;
+- n2s(p, payload);

if (1 + 2 + payload + 16 > s->s3->rrec.length)
return 0; /* silently discard per RFC 6520 sec. 4 */

should not that be written like this:

if (payload > s->s3->rrec.length) //! s->s3->rrec.length)
return 0; /* silently discard per RFC 6520 sec. 4 */

Taken from: http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db902

Re:Integer Overflow on the patch?! (0)

Anonymous Coward | about 6 months ago | (#46711571)

rrec.length is the length of whole packet, which includes message type (HEARTBEAT_REQUEST, 1 byte), payload length (2 bytes), payload (? bytes) and padding.

HTH, HAND.

Re:Coding Style versus Language (0)

Anonymous Coward | about 6 months ago | (#46710415)

Nitpick.
If you are refactoring correctly, you should not eliminate bugs - otherwise you are not doing it right.
It might, as you say, make the bug apparent.

Re:Coding Style versus Language (2)

nanolith (58246) | about 6 months ago | (#46710453)

I meant that the refactor would make the bug obvious. However, as is the case with any bit of refactoring, one often finds bugs, writes test cases to capture these bugs, and then comes back to eliminate them. While the pedantic would argue that refactoring keeps functionality the same, refactoring is just one step in a larger process of code stewardship that includes the isolation and elimination of bugs. When a refactor makes a bug obvious, I contend that the refactor helps to eliminate that bug.

Either way, you are correct: refactoring does not fix bugs. But, in the larger sense, it brings them to light.

Re:Coding Style versus Language (2)

MoonlessNights (3526789) | about 6 months ago | (#46710859)

In my experience, focusing on "coding style" makes code quality drop since it creates a culture where "review" is simply making sure you dotted the i's and crossed the t's without actually reading the sentence.

If there is one common belief held by all developers it is that their style is "correct" while everyone else is "wrong". The only difference is now the define wrong: "ugly", "inconsistent", "unclear", "confusing", "hard to maintain", "brittle", etc. If you want to see what they actually mean, ask them to quantify the problem and they will either get to the point or get very aggressive.

At the end of the day, understanding the logical idea behind the code is the most important thing followed by the correct translation of the idea into a sequential language.

While I don't like the OpenSSL style, personally, I don't see it as being related to this problem.

Re:Coding Style versus Language (5, Insightful)

nanolith (58246) | about 6 months ago | (#46710977)

Style, or the lack thereof, is absolutely related to this issue. It created the festering environment that this bug hid in for two years before it was discovered.

Style is about more than pretty print formatting. It's about avoiding the god-awful raw pointer math found in this function. It's about properly bounding values. It's about enforcing the sorts of checks that come naturally to programmers with more experience and less bravado. You may not appreciate the need for good style yet, but I bet you that the OpenSSL team is rethinking this now. To know that such a sophomoric mistake lingered for two years, even though hundreds of eyes passed over that code, is the epitome of why good programming style matters. The people who looked at this code are likely much smarter than you or I. They could not follow the logic of this code, because their eyes glossed right over this glaring bug. That's bad style. Everything else is window dressing.

Re:Coding Style versus Language (1)

MoonlessNights (3526789) | about 6 months ago | (#46711043)

It's about avoiding the god-awful raw pointer math found in this function. It's about properly bounding values. It's about enforcing the sorts of checks that come naturally to programmers with more experience and less bravado.

This is the definition of "style" which I would like to see more of because I completely agree with that statement. The problem is that I have worked in environments where "style" was literally formatting and it created a culture where nobody could see the forest through the trees and it meant actual quality was pretty terrible (bugs, leaks, etc).

"Style" is a word I keep at a distance since too many developers think it is all about being some definition of "pretty" even though the thing doesn't actually work.

Re:Coding Style versus Language (1)

nanolith (58246) | about 6 months ago | (#46711077)

I can agree with that. Programming style often gets confused with window dressing, which goes against the original guidelines that Kernighan and Plauger laid down in The Elements of Programming Style, many of which are still quite valid today. I refer to this tendency as "cargo cult" programming style, where people attempt to poorly mimic the style guidelines that have been passed down for generations, getting all of the trappings of this original understanding, but none of the substance.

I'm trying to take back the phrase, "programming style", to mean something in the spirit of what Brian Kernighan meant. Sometimes it means that I get a little curmudgeonly about its mis-use. :-)

Re:Coding Style versus Language (1)

TCM (130219) | about 6 months ago | (#46711857)

Wait, you assume it was a mistake?

I've read an assessment that says if you wanted to plant a perfect backdoor, it would look exactly like this.

Re:Coding Style versus Language (0)

Anonymous Coward | about 6 months ago | (#46715795)

ding ding...

The same way "user reviews" have become useless on the internet because companies just started creating their own reviews.

"open source" programing is under assault.

As a hacker trying to exploit for profit, which is easier?

1. Spend years reverse engineering random processes looking for a exploit?

or

2. Spend 6 months infiltrating a open source project you can insert your own exploit into, to give you free reign to everything?

Re:Coding Style versus Language (1)

nanolith (58246) | about 6 months ago | (#46716897)

Whether the flaw was intentional or not is irrelevant. It should not have been possible to commit such a flaw into the codebase without someone noticing.

Re:Coding Style versus Language (0)

Anonymous Coward | about 6 months ago | (#46713433)

There's more to coding style. You also have the *annotations* for static checking in the coding style. Use them well, and the static checker would have complained that you were doing memcpy() on something unsanitized (sort of like the perl taint stuff).

Linux does this for usermode access (copy_from/_to_user), and it helps a *GREAT* deal. Except when it doesn't: it helps not adding extra bugs, though.

Re:Coding Style versus Language (1)

Raenex (947668) | about 6 months ago | (#46711257)

C and C++ are not necessarily the problem. It's true that higher level languages solve this particular kind of vulnerability, but they are not safe from other vulnerabilities. To solve problems like these, we need better coding style in critical open source projects.

It's better to remove a very large class of bugs by the language making them impossible rather than insisting that a certain coding style will save you, "This time for sure!"

Re:Coding Style versus Language (1)

nanolith (58246) | about 6 months ago | (#46717179)

Could a higher level language help? Sure. Is it a realistic and practical solution to OpenSSL's issues? Not really.

I've heard this argument, and I've seen blunders of vulnerabilities in Java, C#, Ruby, Python, and other higher level languages. This is not a language or platform specific problem. It's an industry wide problem. Show me typical code in any language, and I will find bugs in that code. Some of those bugs can be exploited.

The biggest difficulty I have with advocates of higher level languages is that I have a harder time convincing them that bugs in their code can be exploited. "...but, this is Java. It's supposed to be secure." Better languages can help, but they are not a panacea. It takes dedication and hard work to write hardened code.

Re:Coding Style versus Language (1)

Raenex (947668) | about 6 months ago | (#46718383)

Could a higher level language help? Sure. Is it a realistic and practical solution to OpenSSL's issues? Not really.

Buffer overflows are an extremely common security error, especially at the level something like OpenSSL is written at.

I've heard this argument, and I've seen blunders of vulnerabilities in Java, C#, Ruby, Python, and other higher level languages. This is not a language or platform specific problem.

You're arguing because bugs still exist, there's no reason to remove a large class of bugs and it isn't the language's fault. That's nonsense. Buffer overflows are a language problem endemic to C.

Better languages can help, but they are not a panacea. It takes dedication and hard work to write hardened code.

I didn't say it was a panacea. It's still a large class of errors that can be completely removed without the failed advice that we can just code better to avoid them.

Re:Coding Style versus Language (1)

nanolith (58246) | about 6 months ago | (#46718627)

So... we should re-write OpenSSL in a higher level language, yes? About how long is that going to take? How many code bases that currently use OpenSSL will not be able to use this new library, due to portability reasons? Your solution to the problem is impractical.

Should higher level languages be used when possible? Absolutely. I'm a fan of high level languages. I prefer to write software in Haskell and Scala when possible. Is suggesting the use of a higher level language at all helpful here? No.

There is idealism, and then there is pragmatism. I choose to be pragmatic. The problems in the OpenSSL code base are not impossible to solve. OpenBSD is written primarily in C, and compared to OpenSSL, it's light years beyond this library in terms of good programming style and proper use of language constructs. It's not failed advice to argue that these issues can be avoided. It's pragmatic advice, and it's more useful than throwing out a mature library and re-writing it from scratch in a higher level language.

Re:Coding Style versus Language (1)

Raenex (947668) | about 6 months ago | (#46718951)

Should higher level languages be used when possible? Absolutely. I'm a fan of high level languages. I prefer to write software in Haskell and Scala when possible.

This was my main point. Whether it is practical to rewrite OpenSSL in a safe language isn't something I was arguing. To requote what I originally responded to:

C and C++ are not necessarily the problem. It's true that higher level languages solve this particular kind of vulnerability, but they are not safe from other vulnerabilities. To solve problems like these, we need better coding style in critical open source projects.

Re:Situation is a Shambles (1)

Fnord666 (889225) | about 6 months ago | (#46710193)

While something tells me this exploit is somewhat overblown, what really ticks me off is that this is all the result of delegating memory management to C pointers and basically mmap. As far as I'm concerned, in this day and age, that amounts to spaghetti code and I can't say it endears me to the reliability of openssl.

It has nothing to do with mmap or C pointers per se. The issue is simply bad programming. Someone wrote code that trusted unvalidated user input and they got bit in the ass. Whomever performed the code review should have known better, even if the developer didn't..

Re:Situation is a Shambles (1)

nanolith (58246) | about 6 months ago | (#46710209)

I agree. Code review with an eye towards modern programming style would have brought this bug to light years ago.

Re:Situation is a Shambles (1)

Anonymous Coward | about 6 months ago | (#46710463)

I don't get why we have to say "the developer"?

It was Robin Seggelmann that submitted this bit of buggy openssl code. He either works for the NSA or is grossly incompetent...

Re:Situation is a Shambles (1)

phantomfive (622387) | about 6 months ago | (#46710597)

I don't get why we have to say "the developer"? It was Robin Seggelmann that submitted this bit of buggy openssl code. He either works for the NSA or is grossly incompetent...

If competence were a requirement for being a developer, how many developers do you think would be out of work?

Re:Situation is a Shambles (1)

Pieroxy (222434) | about 6 months ago | (#46711769)

I don't get why we have to say "the developer"?

It was Robin Seggelmann that submitted this bit of buggy openssl code. He either works for the NSA or is grossly incompetent...

If competence were a requirement for being a XXX, how many XXX do you think would be out of work?

Please replace XXX by any kind of job title. Cook. Car repair. Teacher. CEO. Anything fits, really.

Re:Situation is a Shambles (0)

Anonymous Coward | about 6 months ago | (#46710737)

You know there are intelligence agencies other than the NSA that would like to subvert encryption standards and implementations.

Re:Situation is a Shambles (4, Insightful)

Jeremi (14640) | about 6 months ago | (#46711207)

It was Robin Seggelmann that submitted this bit of buggy openssl code. He either works for the NSA or is grossly incompetent...

Or he made a dumb mistake, as 100% of programmers have done and will do again in the future. Anyone who expects programmers (even the best programmers) to never make mistakes is guaranteed to be disappointed.

The real issue here is that the development process did not detect the mistake and correct it in a timely manner. Code that is as security-critical as OpenSSL should really be code-reviewed and tested out the wahzoo before it is released to the public, so either that didn't happen, or it did happen and the process didn't detect this fault; either way a process-failure analysis and process improvements are called for.

Re:Situation is a Shambles (1)

TCM (130219) | about 6 months ago | (#46711865)

The whole design of including a variable-sized payload into a heartbeat is completely retarded.

This was either deliberate or Seggelmann is the dumbest fuck on earth.

Re:Situation is a Shambles (0)

Anonymous Coward | about 6 months ago | (#46712385)

Google finds me a claim that there was a reason - so that one could, by trial and error, find the maximum non-fragmenting packet size in the path. :/ shouldn't people be using a transport layer that doesn't depend on that?

Re:Situation is a Shambles (1)

dave420 (699308) | about 6 months ago | (#46712697)

*Whoever.

Re:Situation is a Shambles (0)

Anonymous Coward | about 6 months ago | (#46710223)

I'm running Linux Mint Olivia -- the next to current version -- an no openssl patch is yet available as of this afternoon.

You probably should be running a version of linux that's still supported...that's why there's LTS. The nonbsolete versions of Mint have already been patched.

Re:Situation is a Shambles (0)

Anonymous Coward | about 6 months ago | (#46710281)

Not sure if trolling or not.

Giving you the benefit of the doubt, specific control of memory management is largely required in cryptographic software. Relying on something unknown to manage memory opens you up to side channel attacks (where information is revealed in an indirect way), not to mention holes introduced by the underlying manager.

Re:Situation is a Shambles (1)

rubycodez (864176) | about 6 months ago | (#46710477)

I'm running Petra (16) and patch was out yesterday morning. sucks to be you.

Re:Situation is a Shambles (5, Interesting)

kiite (1700846) | about 6 months ago | (#46710479)

This is not a memory management issue per se, and has nothing to do with mmap or malloc. In fact, the malloc succeeds just fine. Rather than just explaining in text, it might be easier if i simplify the issue in C parlance (this would look neater if slashdot allowed better code formatting):


char *rec_p = record; // record pointer
uint16_t rec_len = SSL3_RECORD_LEN; // hi! i'm ignored.
uint16_t user_len = *(uint16_t*)rec_p; // user_len = user-supplied length
rec_p += sizeof(uint16_t); // rec_p points to start of user payload
char *buf = malloc(user_len); // allocate using user-supplied length
memcpy(buf, rec_p, user_len); // copy user_len bytes from record
reply(buf); // reply with said data

Due to the fact that this code works more or less exactly as designed, the exploit functions across architectures and operating systems. This bug is so amateurish, i almost find it difficult to believe that it was unintentional.

Re:Situation is a Shambles (2, Interesting)

Raenex (947668) | about 6 months ago | (#46711235)

This is not a memory management issue per se, and has nothing to do with mmap or malloc.

But what the grandparent post said still applies. It's how C treats memory via pointers. The issue, from looking at the code you posted, is that memcpy() copies from beyond the length of rec_p. In a sane language that doesn't treat memory as free-for-all, this isn't possible.

Due to the fact that this code works more or less exactly as designed, the exploit functions across architectures and operating systems. This bug is so amateurish, i almost find it difficult to believe that it was unintentional.

It's the kind of mistake programmers make all the time in C. Sure, you can tell me battle-hardened, conscientious, professional programmers wouldn't make this mistake. Whatever, we've seen this kind of thing too many times for this sentiment to mean anything practically useful.

Re:Situation is a Shambles (2, Informative)

swillden (191260) | about 6 months ago | (#46711421)

This is not a memory management issue per se, and has nothing to do with mmap or malloc.

But what the grandparent post said still applies. It's how C treats memory via pointers. The issue, from looking at the code you posted, is that memcpy() copies from beyond the length of rec_p. In a sane language that doesn't treat memory as free-for-all, this isn't possible.

No, that's not the issue, in fact there really isn't any significant pointer arithmetic used here. Yeah, it does use a bit to pull the size field out of the incoming request, but there's nothing wrong with that part of the code.

The issue is that the code allocates a buffer of a size specified by the user, without validating it, and doesn't zero the allocated memory. Yes, many languages automatically zero heap-allocated arrays, which is good, but it's also a performance cost which is often unnecessary and there's nothing wrong (IMO) with not doing it by default. There is, however, plenty wrong with just accepting a user-provided value without validation, and with not completely overwriting heap-allocated memory before sending it.

Re:Situation is a Shambles (0)

Anonymous Coward | about 6 months ago | (#46711705)

Probably a newbie question, but why does buf need to be initialized to zero? I agree that it is proper coding behavior to initialize allocated memory, but in my opinion, its initial value must be a sane value, not necessarily zero. If buf were initialized to zero, aren't all those zeroes overwritten by the memcpy statement? I think that we can regard the memcpy as the initialization of buf. So, as far as I can see, buf is properly initialized. Am I overlooking something?

Re:Situation is a Shambles (1)

swillden (191260) | about 6 months ago | (#46713859)

No, you're right and I was wrong. It's the memcpy call that causes the problem. For that matter, I have to concede the GPs point, at least partially. It's allowing memcpy to run off the end of rec_p that is the problem. I was thinking the garbage was left over in the allocation of buf, but that isn't the issue. I should have more than glanced at the code; I kind of fixated on the first dumb problem I saw.

Re:Situation is a Shambles (2)

kukulcan (1440401) | about 6 months ago | (#46712051)

The parent is right. The issue is with the memcpy(), not the malloc. Even if malloc() zeroed the memory there would still be an issue, because it is getting overwritten by memcpy. The issue is the size of the memcpy(), which is simply user-provided (up to max uint16).

Re:Situation is a Shambles (0)

Anonymous Coward | about 6 months ago | (#46723371)

This is not a memory management issue per se, and has nothing to do with mmap or malloc.

But what the grandparent post said still applies. It's how C treats memory via pointers. The issue, from looking at the code you posted, is that memcpy() copies from beyond the length of rec_p. In a sane language that doesn't treat memory as free-for-all, this isn't possible.

No, that's not the issue, in fact there really isn't any significant pointer arithmetic used here. Yeah, it does use a bit to pull the size field out of the incoming request, but there's nothing wrong with that part of the code.

The old parent means languages which do bounds checking on arrays and records. Those would raise an exception on the copy operation which goes beyond the record (or array) end. That means the data from memory behind the record would not be leaked to the outside world. So the old parent is right.

Re:Situation is a Shambles (1)

m.alessandrini (1587467) | about 6 months ago | (#46711621)

It's also incredible that nobody spotted it before. It must be something like that that was exploited in Matrix 2 to break ssh...

Re:Situation is a Shambles (1)

matthewmok (412065) | about 6 months ago | (#46714103)

So then...who committed this piece of code?

Re:Situation is a Shambles (0)

Anonymous Coward | about 6 months ago | (#46714349)

This bug is so amateurish, i almost find it difficult to believe that it was unintentional.

  Unfortunately, if it was 'intentional' it would probably look much more obscure that nobody can read it. The fact that you point out it is "amateurish", is exactly that.

Re:Situation is a Shambles (1)

CODiNE (27417) | about 6 months ago | (#46710567)

So "shambles" means user supplied data...
eating it without question means not validating it before use...

1 Cor. 10:25 "Whatsoever is sold in the shambles, that eat, asking no question for conscience sake"

then.. uhhh...
Wait.. is this a GOOD thing??

Re:Situation is a Shambles (2)

MoonlessNights (3526789) | about 6 months ago | (#46710819)

This has little to do with any C-specific. If you were re-using a buffer in some managed runtime, you would still see the same problem.

The problem is related to a missing check on a user-provided value. It is a pretty common kind of bug, really, since it is isn't often obvious which level of the stack was supposed to check it (hence why assertions are helpful - this would have been a crash, rather than a security hole).

The unfortunate thing is that this kind of bug detection isn't easily automated (since it is a logical oversight, not something actually incorrect). The only reason why this one got so much attention is because so many people rely on it for, ironically, security.

Logical oversight is not specific to one language or even kind of language so we will be fighting this kind of bug until the end of time (just like how we still deal with it in the real world - this isn't even computer-specific).

Re:Situation is a Shambles (1)

Eunuchswear (210685) | about 6 months ago | (#46711245)

Write your code in Perl with taint checking on.

1/2 joke.

Re:Situation is a Shambles (1)

swilly (24960) | about 6 months ago | (#46711313)

This has little to do with any C-specific. If you were re-using a buffer in some managed runtime, you would still see the same problem.

Most managed runtimes perform bounds checks, C does not. As a result, the same bug couldn't happen in Java or C#. Of course, bounds checks come with a cost, and one that most people wouldn't want from low level code, which means that C/C++ developers must be extra vigilant.

Re:Situation is a Shambles (3, Informative)

iroll (717924) | about 6 months ago | (#46711373)

That sounds like a Mint thing. Seriously, Debian (the great grandparent of Mint) had the patch as fast as anybody. Heck, by the time I logged into my Mac at work, MacPorts had pushed the patch.

I wouldn't make such a sweeping statement about the "situation" when you've hitched your wagon to a project that's pulling from a project that's pulling from a project that's (etc).

Re:Situation is a Shambles (0)

Anonymous Coward | about 6 months ago | (#46712175)

I'm not sure if it was outdated by the time they posted here, but yesterday (Wednesday) I checked my Linux Mint 13 install (Maya - the Long-Term Support version), and it had the OpenSSL patch in the regular updates. It didn't take long.

Re:Situation is a Shambles (0)

Anonymous Coward | about 6 months ago | (#46712543)

It's not a Mint thing, it's a "use a supported operating system" thing. Support for Mint Olivia ended in January, along with Ubuntu 13.04 that it's based on. "If your version of Ubuntu is not listed above, it is no longer supported and does not receive security or critical fixes." [ubuntu.com]

Re:Situation is a Shambles (1)

iroll (717924) | about 6 months ago | (#46715327)

Well, that just makes OP all the more rediculous. I can't believe he's modded to 5 now.

Re:Situation is a Shambles (2)

Ash Vince (602485) | about 6 months ago | (#46713565)

That sounds like a Mint thing. Seriously, Debian (the great grandparent of Mint) had the patch as fast as anybody. Heck, by the time I logged into my Mac at work, MacPorts had pushed the patch.

I wouldn't make such a sweeping statement about the "situation" when you've hitched your wagon to a project that's pulling from a project that's pulling from a project that's (etc).

Interestingly our Debian servers are completely unaffected by this bug since we use Debian 6 :) Sometimes it pays to be a little behind the times.

Hmmm (1)

koan (80826) | about 6 months ago | (#46710157)

PFsense VRT rules (paid version) already updated, I'm sure every maintained IDS has been updated for this.

Don't forget about the other recent problems (0)

Anonymous Coward | about 6 months ago | (#46710183)

Before anyone uses this as a attack against open source, then please remember the compromise of RSA by the NSA. That was a deliberate, wilful violation of trust with wide-reaching consequences.

Also, don't forget that little issue in the Apple source code recently...

BTW, is there any evidence this was a NSA job as opposed to just a screwup by a developer ?

Re:Don't forget about the other recent problems (1)

NiteMair (309303) | about 6 months ago | (#46710201)

And don't forget the GnuTLS failure similar to Apple's

Now we're just waiting to hear that Microsoft's IIS was also borked in some unexpected way, and it'll be a royal flush eh?

Re:Don't forget about the other recent problems (1)

cbhacking (979169) | about 6 months ago | (#46710493)

Well, Microsoft's CAPI (CryptoAPI) actually, not IIS. IIS uses CAPI, but IIS is no more a crypto toolkit than Apache or lighttpd are. A vuln in CAPI (they've happened before) could also affect clients (IE, Outlook, anything else using the platform APIs...).

Besides, we're still waiting on a NSS issue. NSS isn't so much *broadly* used - I know of only a few product families that use it - as it is *heavily* used. The product families in question are Mozilla anything (Firefox, mostly; the N stands for "Netscape") and Chrome (for PCs). Very few browsers (though not zero; Chrome on Android 4.1 uses a vulnerable version of OpenSSL) are/were vulnerable to Heartbleed, but they'll get their turn eventually!

Re:Don't forget about the other recent problems (1)

kharbour (559204) | about 6 months ago | (#46714869)

Whichever way you look at it, this isn't a great day for open source software though is it. And I speak as an advocate, i.e. recommending using Linux over Windows for servers, because of, you know, security. Can't help feeling a little bit embarrassed at the moment.

OSX not affected? (1)

DaveyJJ (1198633) | about 6 months ago | (#46710301)

I've now read that: "No versions of OS X or OS X Server are affected by the OpenSSL Heartbleed bug, because the last version of OpenSSL shipped by Apple in an OS was 0.9.8y, which is a branch not affected by this bug. So unless you've installed OpenSSL via MacPorts or Homebrew, your public-facing OS X servers/services should be immune to this bug." What say the wise ones here?

Re:OSX not affected? (2)

Iarwain Ben-adar (2393286) | about 6 months ago | (#46710421)

Phew. At least 2 websites are safe!

Re:OSX not affected? (0)

Anonymous Coward | about 6 months ago | (#46712673)

2??? when did they get that second, citation or it didn't happen.

Re:OSX not affected? (1)

rubycodez (864176) | about 6 months ago | (#46710449)

Maveriks has openssl version 0.9.8y, which is too old to be vulnerable. Macports will give you a vulnerable 1.0.1 version that last I checked earlier today had no patch.

Re:OSX not affected? (1)

cbhacking (979169) | about 6 months ago | (#46710539)

0.9.8 doesn't support any protocol newer than TLS 1.0, so while it's safe from heartbleed it's also old and verging on deprecated.

Also, it's not that rare for software to use its own copy of OpenSSL, either is a bundled library or statically compiled into the program. I don't actually know of any Mac software that I'm sure does this, but that's not saying much since I don't use a Mac. Things I would expect to find it in are cross-platform programs that use OpenSSL but want a newer branch than 0.9.8 (Python maybe?)

Re:OSX not affected? (0)

Anonymous Coward | about 6 months ago | (#46710627)

Because Apple has deprecated OpenSSL, and recommended applications to bundle their own version, it's a fair bet a substantial number of Mac applications bundle OpenSSL. iOS never had OpenSSL, and many, many iOS applications bundle OpenSSL--because Mac's crypto lib is woefully inadequate for doing complex things like key management; it's basically a cipher library with a simple SSL layer.

Is there a way to tell? (1)

scorp1us (235526) | about 6 months ago | (#46710333)

Like some site that is (like "what that site is running?" (Apache, IIS etc)) where we can see who gets what fixed when. No point in changing my passwords on a still-affected site.

Re:Is there a way to tell? (4, Informative)

Riddler Sensei (979333) | about 6 months ago | (#46710429)

Qualys SSL Test [ssllabs.com] is including a flag for Heartbleed vulnerability and auto-fails any domain tested that is affected.

Re:Is there a way to tell? (2, Informative)

Anonymous Coward | about 6 months ago | (#46710447)

Re:Is there a way to tell? (1)

rubycodez (864176) | about 6 months ago | (#46710469)

there are scripts that can scan for the vulnerability. I'm amused that many major banks, credit card companies and a certain well known pay-your-friend site (at least a couple of their URL, not all their services) have neither acknowledged the bug, nor patched it.

Re:Is there a way to tell? (1)

El_Oscuro (1022477) | about 6 months ago | (#46710555)

You could just go to http://www.netcraft.com which has a search function to do just that.  They also have an anti-fishing toolbar which will give very detailed information about a site.  For example:

Site title     Slashdot: News for nerds, stuff that matters     Date first seen     September 2004
Site rank     5747     Primary language     English
Description     Not Present
Keywords     Not Present
Network
Site     http://it.slashdot.org     Netblock Owner     SourceForge, Inc.
Domain     slashdot.org     Nameserver     ns1.p03.dynect.net
IP address     216.34.181.48     DNS admin     hostmaster@corp.sourceforge.com
IPv6 address     Not Present     Reverse DNS     star.slashdot.org
Domain registrar     pir.org     Nameserver organisation     whois.dyndns.com
Organisation     Dice Holdings, Inc., New York, 10018, US     Hosting company     Dynamic Network Services, Inc.
Top Level Domain     Organization entities (.org)     DNS Security Extensions     unknown
Hosting country      US
Hosting History
Netblock owner     IP address     OS     Web server     Last seen Refresh
SourceForge, Inc. 12150 Meredith Drive Urbandale IA US 50323     216.34.181.48     unknown     Apache/2.2.3 CentOS     13-Dec-2013
</pre>

Re:Is there a way to tell? (0)

Anonymous Coward | about 6 months ago | (#46710557)

Well, sites affected by heartbleed should have revoked all certs and private keys and got new ones. So sites that have fixed the bug should have new certs issued shortly after they patched their systems.

Several! (4, Informative)

cbhacking (979169) | about 6 months ago | (#46710579)

There have been a number of sites.
SSLLabs scanner has been updated to check for Heartbleed, and also will report when the cert validity starts (handy if you want to see whether they're using a new cert). https://www.ssllabs.com/ssltes... [ssllabs.com]
LastPass has a pretty decent scanner that just focuses on Heartbleed (without all the other info that you get from SSLLabs): https://lastpass.com/heartblee... [lastpass.com]
There are some others out there as well, of course.

There's even one for client-side testing (almost as critical):
Pacemaker is an awesome little POC script (python 2.x) for testing whether a *client* is vulnerable (many that use OpenSSL are...). https://github.com/Lekensteyn/... [github.com]

Re:Is there a way to tell? (2)

vic-traill (1038742) | about 6 months ago | (#46710591)

The only client side tool I've encountered is at http://filippo.io/Heartbleed/ [filippo.io] Can't speak to the implementation or even if it actually checks. But it purports to check in real time and if you trust it you can check sites prior to changing passwords.

Re:Is there a way to tell? (1)

dr_blurb (676176) | about 6 months ago | (#46711671)

I used the http://filippo.io/Heartbleed [filippo.io] page before and after patching my server, and it appears to work ok (reported "vulnerable" before, and "fixed" after).

Re:Is there a way to tell? (0)

Anonymous Coward | about 6 months ago | (#46712413)

Just hope when it reported vulnerable it didn't also give your host/IP to a bunch of hackers or the site itself didn't start exploiting your server itself.

FreeBSD 8.2 and openssl-0.9.8 FTW (0)

Anonymous Coward | about 6 months ago | (#46710399)

Oh, and PPC too.

Let the script kiddies do their best. Bwa ha ha ha ha

Re:FreeBSD 8.2 and openssl-0.9.8 FTW (1)

rubycodez (864176) | about 6 months ago | (#46710771)

your popular PHP5 platforms will be so safe on that

Tax Office Closed (1)

Anonymous Coward | about 6 months ago | (#46710669)

The Canadian Revenue Agency has shut down online reporting of taxes. 80% of Canadians use this service and most corporations file electronically anyway. Get ready for a wave of paper heading for Sudbury!

http://www.cra-arc.gc.ca/menu-eng.html

Where's the changelog entry for this (1)

viperidaenz (2515578) | about 6 months ago | (#46710835)

Is bypassing/wrapping/whateverthey'redoing OS calls changing how memory is managed not a big enough change to warrant an entry in the 1.0.0h -> 1.0.1 log?

Reality Check. The sky is not falling. (4, Informative)

thesandbender (911391) | about 6 months ago | (#46710853)

One of my current roles is to provide technical support/advice for a group of project managers and business analysts. This morning a few of them had watched the Crash News Network over breakfast and came in convinced that privacy, as we know it, had come to an end. My job is to talk them off the ledge (and I actually enjoy it, they're smart people and as long as I explain it correctly, they get it... I've found that's pretty rare).

1. The issue only exposes 64k at a time. Let's assume that the average enterprise application has at least a 1G footprint (and that's actually on the low end of most applications I work with). That's 1,048,576K. At best, this means that this exploit can access 0.006% of memory of an applications memory at one time.

Ahh you say, I will simple make 16,667 requests and I will retrieve all the memory used by the application.

2. The entire basis of this issue is that programs reuse memory blocks. The function loadAllSecrects may allocate a 64k block, free it and then that same block is used by the heartbeat code in question. However, this code will also release this same block which means that the block is free for use again. Chances are very good (with well optimized code), that the heartbeat will be issued the same 64k block of memory on the next call. Multi-threaded/multi-client apps perturb this but the upshot is that it's NOT possible to directly walk all of the memory used by an application with this exploit. You can make a bazillion calls and you will never get the entire memory space back. (You're thinking of arguments to contrary, your wrong... you wont.)

Congratulations, much success... you have 64k internet.

3. Can you please tell me where the passwords are in this memory dump:

k/IsZAEZFgZueWNuZXQxFzAVBgNVBAMTDk5ZQ05FVC1ST09ULUNBMB4XDTEwMDMw
MzIyNTUyOFoXDTIwMDMwMzIyMTAwNVowMDEWMBQGCgmSJomT8ixkARkWBm55Y25l

There will be contextual clues (obvious email addresses, usernames, etc) but unless you know the structure of the data, a lot of time will be spent with brute force deciphering. Even if you knew for a fact that they were using Java 7 build 51 and Bouncy Castle 1.50, you still don't know if the data you pulled down is using a BC data structure or a custom defined one and you aren't sure where the boundaries start and end. The fact that data structures may or may not be contiguous complicates matters. A Java List does not have to store all members consecutively or on set boundaries (by design, this is what distinguishes it from a Vector).

Long story short. Yes, there is a weakness here. However, it's very hard to _practically_ exploit... especially on a large scale (no one is going to use this to walk away with the passwords for every gmail account... they'd be very, very lucky to pull a few dozen).

This doesn't excuse developers from proper programming practices. It's just putting "Heartbleed" in perspective.

Re:Reality Check. The sky is not falling. (2)

viperidaenz (2515578) | about 6 months ago | (#46710967)

But you know the vulnerable host is running OpenSSL 1.0.1 -> 1.0.1f, so you can look at the source code to figure out what the memory around the private key is supposed to look like.

Re:Reality Check. The sky is not falling. (1)

colfer (619105) | about 6 months ago | (#46711011)

This guy has retracted part of his analysis based on comments, but tries to make a case that passwords and cookies in the http headers are more likely to be exposed than keys. Remember, http-auth is still used a lot. http://blog.erratasec.com/2014... [erratasec.com]

Re:Reality Check. The sky is not falling. (1)

columbus (444812) | about 6 months ago | (#46727975)

Damn. No mod points. Somebody mod the parent post up please. This is pertinent and informative.

Re:Reality Check. The sky is not falling. (1)

phantomfive (622387) | about 6 months ago | (#46711087)

I'm not sure where all the frenetic press came from. Surely there have been other vulns that are more severe? Like maybe one of these? [zdnet.com]

Re:Reality Check. The sky is not falling. (1)

bloodhawk (813939) | about 6 months ago | (#46711815)

none of those are even in the same ballpark of criticality compared to this vulnerability. All of them combined don't even come close.

Re:Reality Check. The sky is not falling. (1)

phantomfive (622387) | about 6 months ago | (#46715313)

That's only true if you believe company's secret keys are all being compromised, which they aren't.

Re:Reality Check. The sky is not falling. (5, Informative)

pop ebp (2314184) | about 6 months ago | (#46711379)

I am tired of people downplaying the severity of this bug.

Can you please tell me where the passwords are in this memory dump ...

Have you ever seen a real exploited piece of data?
These are taken from Yahoo production servers, a day or two ago:

http://cdn.arstechnica.net/wp-... [arstechnica.net]
http://cdn.arstechnica.net/wp-... [arstechnica.net]

Can you guess where the password is, now? (And those didn't even take that many tries)

I have not seen actual SSL private keys floating around just yet, but given that the original researchers said [heartbleed.com] they managed to get private keys from their own servers, I think it is reasonable to assume that some production servers must have already leaked them.

Re:Reality Check. The sky is not falling. (1)

advocate_one (662832) | about 6 months ago | (#46712639)

all the more reason to have encrypted memory

Re:Reality Check. The sky is not falling. (0)

Anonymous Coward | about 6 months ago | (#46712737)

So two yahoo accounts were affected?

Re:Reality Check. The sky is not falling. (0)

Anonymous Coward | about 6 months ago | (#46713495)

You can auto-detect key material on any memory dump. You look for binary and base-64-encoded regions of high entropy. This also flags compressed data, but that's very rarely present on memory dumps. You will also find truly random data (as in random numbers used for crypto), but keys usually have internal structure, so it is not too difficult to separate both automatically.

Re:Reality Check. The sky is not falling. (0)

Anonymous Coward | about 6 months ago | (#46714105)

Oh snap, tell OP to apply lotion to the burn...

Re:Reality Check. The sky is not falling. (1)

phantomfive (622387) | about 6 months ago | (#46715253)

The only way to get private keys is to attack a BSD system before anyone else makes a request. At least that's the only report I've found that was successful. Not likely to be practical in the real world.

IDS signatures might not work in all cases (2)

mysidia (191772) | about 6 months ago | (#46710913)

While the proof of concept exploit used an unencrypted attack, the vulnerability can still be exploited AFTER the session is encrypted.

Since the IDS probably cannot decrypt the SSL connection... it is unlikely to detect an attack that occured after encryption was negotiated, and the extension message is invisible to the IDS

what is the point of IDS? (1)

manu0601 (2221348) | about 6 months ago | (#46710979)

What is the point of IDS? If you detect an attack, your private keys are compromised and the game is over.

And then you try to recover, you make new keys, renew certificates, revoke the old one... but since certificate revocation is quite broken, you never recover. An attacker that stole your old private key will still be able to masquerade as the legitimate server.

Re:what is the point of IDS? (1)

ruir (2709173) | about 6 months ago | (#46711341)

Ever had of IPS, or an IDS feeding a firewall?

Tell your users, too! (1)

Just Some Guy (3352) | about 6 months ago | (#46711003)

Follow the proposed specification at http://heartbleedheader.com [heartbleedheader.com] to tell your users when you've patched your servers. This eliminates the guessing: "is it OK to update my password now? Do I even need to? Can I trust that I'm not being MITMed with their old SSL key that an attacker stole?" It's bad enough using the tools at hand to detect that information from a single site, let alone the hundreds you might have in your password manager.

What I want to know is... (1)

jonwil (467024) | about 6 months ago | (#46711397)

If OpenSSL is (as quite a few people who know what they are talking about have claimed) poorly written and hard to maintain, why no-one has tried to come up with a simple, easy to evaluate solution.

Or is SSL/TLS really that hard to properly implement?

Re:What I want to know is... (1)

kthreadd (1558445) | about 6 months ago | (#46711539)

People have, it's called nss.

Re:What I want to know is... (1)

colfer (619105) | about 6 months ago | (#46712115)

Here's a sad post from one year ago:

Is it possible to ensure by a configuration parameter, that curl uses OpenSSL, and not NSS to retrieve https content? I need to ensure this, in order to enforce compliance with FIPS140-2, which RHEL6.2 has certified?

http://stackoverflow.com/quest... [stackoverflow.com]

By the way I know NSS does a lot of FIPS compliance, but part of the Heartbleed problem for the "normal" user is that it is hard to tell what openssl is linked into. We had it in our web server daemon even though shell "openssl version" showed a good version.

Think about this bug vis a vis SourceForge... (1)

decaffeinated (70626) | about 6 months ago | (#46711459)

Suppose SourceForge is/was vulnerable (I don't know that that's the case...I opened a ticket to find out).

Suppose a developer's login credentials were grabbed before SourceForge reacted and closed the hole.

Great. Now a bad character can upload malware as the latest release for any of the compromised developer's SourceForge projects.

Yeah...chew on that.

H1Z1 - may be better than DayZ! from SOE - F2P (0)

Anonymous Coward | about 6 months ago | (#46711873)

http://slashdot.org/firehose.p... [slashdot.org]

Note: I am not the author of the following quote, this is a copy/paste.

http://www.reddit.com/r/h1z1 [reddit.com]

http://www.reddit.com/r/h1z1/c... [reddit.com]

"Hi there,

I wanted to tell you about an exciting new free-to-play game we've had under wraps here at SOE for some time. It's called H1Z1. It's a massively multiplayer game in which players fight for survival in a world where death is the only sure thing. The H1Z1 virus devastated mankind and left nothing but death and destruction in its wake and a world nearly empty of human life where the remnants of humanity are in a fight against extinction against those infected with the virus. It's been 15 years since H1Z1 was first encountered and what's left of the world before is overrun with the Infected. Humanity has been reduced to hiding in the shadows, searching desperately for food and water and anything that can help to survive even for another day. But the Infected aren't the only dangers in the world. Everyday life in the Apocalypse means dealing with all kinds of wild animals and the brutality of other survivors, as well as finding your next meal and a safe place to sleep. It also means scavenging or crafting anything that can help you live just one more day. In H1Z1 every minute of every day is borrowed time and fearing for your life.unless you are the Danger (talking to you Walter), but life can and will go on.even in circumstances as dire as this. Humanity has not given in to the Infected. There are still pockets of humanity and the fight goes on!

Our vision for this game is very simple but ambitious. We are starting with what I would call "Middle America" - an "anywhere and everywhere" town. The world is massive as you've come to expect from our games. Over time we will grow the world until we have our own version of the U.S. after the death and destruction brought on during the H1Z1 epidemic. It will be our own version of America. We'll have urban cities and desolate wide open places. All connected seamlessly. Our focus is building a sandbox style of gameplay where players can build shelters out of resources in the world. They can even work together to make amazing fortresses complete with weaponry to help defend against both the Infected and other players. Players also have access to a very deep crafting system that can let players make a huge variety of awesome stuff, including weapons (I made a 1911 the other day) and things like Molotov cocktails, explosives.. and other fun surprises.

I will also go right to the heart of the question a lot of players will have - "There are a lot of survival / Zombie games.how is this one going to be any different?". First off, it's a persistent MMO that can hold thousands of players on servers we host (yes there will be multiple servers with very different rule sets). Why is that a good thing? It means a thriving economy (oh yes.there's trading). It also means you have potential allies in the all-out war on the Infected... and many an enemy as well. It uses our proprietary next-gen Forgelight engine and that means we've had a lot of really cool technology to work with to make the game we wanted to make. It's also designed from the ground up for our players to become part of the design process. The Roadmap system that we built for PlanetSide 2 will be used extensively to clearly communicate what features we're working on and what you can expect and when. You're also going to be getting awesome access to our developers. We'll be opening it up for Player Studio creations too so expect player-created items to make their way into the game. The main thing that differentiates H1Z1 from the other great games in the genre is the emphasis we are putting on player ownership and building. We want you to be able to form roving gangs that are headquartered out of an abandoned warehouse that you've taken over... or a house you've built from scratch after having cut trees down and secured the resources to make it. We are giving players the tools to make their own towns, camps and defenses, and they can decide how to set up their base (which is in the world btw... not instanced). We're building in all the social features you've come to expect from an SOE game (grouping, proximity voice chat, voice chat for your gang, and many other cool social features).

To use a simple reference I'm sure everyone interested in this game will get... we want our players to make Woodbury from The Walking Dead if they want to. Or take over a prison. Or fix an old car so you and your friends (yeah we have multiplayer vehicles) can run zombies and players over mercilessly, and revel in the sheer delight of hearing a zombie scream as you light it on fire, or craft a gun to take down your friends and enemies alike. Our goal here is to provide emergent gameplay that will allow our players to make the world their own the way they want to. One of the best things about H1Z1 being an MMO is the fact that with a lot of people playing, we're able to see all different kinds of gameplay. If you prefer a quiet life as a farmer raising crops... we're going to make sure your zombie apocalypse fantasy is complete. If you're like me and you want nothing more than to kill everything that moves, by all means see how that goes. It's going to be a blast!

Check out http://www.h1z1.com/ [h1z1.com] and the subreddit ( http://reddit.com/r/h1z1 [reddit.com] ). We'll be adding more information in the coming weeks to the website. We'll also be very openly answering questions in the subreddit.

Next week you can see us do a livestream of the game as we have a playtest. Stay tuned!

Smed"

- http://www.reddit.com/user/j_s... [reddit.com]

** What we've learned now:

http://www.reddit.com/r/h1z1/c... [reddit.com]


PC Gamer at 00:33 on 10 April 2014
Story: http://www.pcgamer.com/2014/04... [pcgamer.com]

Archived: https://archive.is/kbRot [archive.is]

Revocation, re-issuing, etc. (1)

barcarolle (581253) | about 6 months ago | (#46711987)

What really needs to be done with certs? Do they really need to be revoked and reissued? Must the re-issued cert have a new issue date? At least one service provider I work with has claimed they somehow reissued their certificate, but it has the same, old issue date and a different signature. Is this enough?

Re:Revocation, re-issuing, etc. (0)

Anonymous Coward | about 6 months ago | (#46716063)

Yes, they need to be revoked and reissued. Strange that your issue date is old; everything I've seen is new. Perhaps you should contact them?

Here's an idea on how BAD this is (0)

Anonymous Coward | about 6 months ago | (#46712599)

The Heartbleed security bug leaks private keys and certificates for https sites (along with other stuff, such as user/password pairs for users of those sites).

Thus, if these certificates are not REVOKED, and these revocation certificates are not DISTRIBUTED to everyone, they can be used to impersionate the site.

This includes even EV certificates.

It is *not* feasible to revoke so many certificates, at all. It is downright impossible except by using OCSP + stapling, which is not only NOT enabled by default in the vast majority of the browsers, it would also cause severe privacy issues (OCSP servers know what sites you access) and operational issues (OCSP servers going down because of the load).

Therefore, the CA certificates themselves will have to be revoked (and sent to the browser vendors to be included in the internal revocation list), which means *EVERY* certificate still valid for that CA, even those of servers that were not affected, will have to be reissued. Either that, or worse, the very CA root certificates have to be replaced, invalidating just about every certificate that CA ever signed, including other CA's. These certificates have NOT been compromised, but replacing them might be the only way to revoke the millions of certificates that might have been compromised.

IIS (1)

Kultiras (2589819) | about 6 months ago | (#46713851)

Perhaps today is a good day to run IIS!

Role of the NSA (0)

Anonymous Coward | about 6 months ago | (#46714187)

This particular bug may not have been as slam dunk bad as originally published, but for this question, assume that it was.

As a point of public debate, do we want the NSA to
      a) Find and exploit these sorts of bugs?
      b) Find and fix these sorts of bugs?

There is an argument that each behavior makes us 'safer'.

Plan a may catch a few bad bad guys, but leaves us open to exploits from other bad guys.
      This makes doing anything important online trickey.
      This will affect daily life.

Plan b probably closes an important window into what some bad folks might do.
      This might prevent another 9-11, but the cost seems very high.

It's not fair to ask the NSA to do both.
    It's a tough choice, but I think the wise choice is to vote for plan b.

I wonder what these comments would look like (1)

Toreo asesino (951231) | about 6 months ago | (#46714237)

...if Microsoft has released something with a bug like this. Somehow I doubt there'd be so much analysis. To me this demonstrates that open != secure necessarily; how long has anyone been able to read the source-code here and even known about it for months? Let's just all agree that open-sourcing code is no guarantee of any kind of quality.

would ssh-keygen certs be affected? (1)

rewindustry (3401253) | about 6 months ago | (#46715941)

my "unwilling to wade in the bulls" take on this affair is that some part of ssl on the outward face of that service is bleeding large chunks of raw memory, in response to a trivial attack.

i'm not clear on on is which parts of memory are bleeding..

only ssl services memory?

or all memory from all services in the vicinity?

or all memory in general?

i'm hearing that sll privates are amonst the things that are leaking, but can anyone please clearly define which parts of my various systems have been wide open to the world, these past two years and more?

some people are saying ssh is not affected..

this is important to me - i don't care about ssl, and consider the bulk of the applications it supports to be trivial, but i cannot work without ssh, and am not aware of any viable alternatives.

i've always assumed that ssh was built on top of ssl - as in why reinvent the wheel - but when i went digging, trying to sort out which versions i have been running, and what i need to update, etc, i seem to be finding that ssh is actually standalone, apparently?

perhaps built on similar principles, but by differerent groups, and never merged - or do i have a bent picture?

apparently i need to learn more about these things - in matters like this i prefer to be able to read the source than listen to pundits pound the keys..

i am one, so i know, don't argue with me.

anyway - hello - if anyone can please enlighten or point at the histories of both open ssl and ssh for me, it would be a great help,

and if anyone could please point at, or repeat the answer to my question about what exactly has been exposed - thank you.

Does not eat his own dogfood (0)

Anonymous Coward | about 6 months ago | (#46717461)

https://www.robin-seggelmann.de/ [robin-seggelmann.de]

Gentoo tls-heartbeat USE flag (1)

trigggl (758335) | about 6 months ago | (#46724573)

After updating my openssl in Gentoo Linux, I noticed that there is a USE flag for 'tls-heartbeat'. So, I have now removed that use flag from all of my Gentoo installs.

Is there any useful reason to keep heartbeat around?

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?