back to article Running OpenSSL? Patch now to fix CRITICAL bug

Sysadmins using the OpenSSL cryptographic library have an urgent job: patching a memory leak vulnerability that could reveal user IDs and passwords. Dubbed “Heartbleed”, the vulnerability was discovered by Google Security's Neel Mehta and announced by CloudFlare. As the terse OpenSSL advisory states: “A missing bounds check in …

COMMENTS

This topic is closed for new posts.
Bronze badge
Windows

patches and version numbers

https://launchpad.net/ubuntu/trusty/+source/openssl/1.0.1f-1ubuntu2

Looks like Ubuntu have patched the 1.0.1f package rather than pushing the new version out. Update arrived early this morning for the 14.04 beta. It appears to be a debian patch.

https://access.redhat.com/security/cve/CVE-2014-0160

Redhat have popped out a patch for EL6.5 (6.4 OK as uses older version, not affected by coding error).

1
0
Anonymous Coward

Re: patches and version numbers

Glad I migrated all my webservers off of Linux over a year ago. Sooooo many patches to evaluate.

3
12
Anonymous Coward

Re: patches and version numbers

We really need a troll icon...

4
0
Bronze badge
Trollface

Re: patches and version numbers

i think we have one...if you are not AC.

2
0
Anonymous Coward

Re: patches and version numbers

Look at all those downvotes. They love to give it, but they sure can't take it.

Heh heh.

1
0
Bronze badge

Re: patches and version numbers @AC

Are you sure the platform you've migrated to isn't using OpenSSL?

Worth testing your servers (web, remote access gateways etc.) against: http://filippo.io/Heartbleed/

Just done this for a couple of clients who permit SSL remote access to their systems, but don't run *nix

Best to be sure you're not vulnerable...

1
0
Anonymous Coward

Re: patches and version numbers

"Glad I migrated my Linux servers OFF OF ...."

And in English:

"I'm glad I migrated my Linux servers FROM ..."

What is it about prepositions that Americans find so difficult?

0
0

RHEL updates are available:

https://rhn.redhat.com/errata/RHSA-2014-0376.html

CentOS updates are available:

http://lists.centos.org/pipermail/centos-announce/2014-April/020249.html

Fedora updates are available, hitting the mirrors, but you can get it earlier, instructions here:

https://lists.fedoraproject.org/pipermail/announce/2014-April/003205.html

https://lists.fedoraproject.org/pipermail/announce/2014-April/003206.html

3
0
Silver badge

OpenSUSE also available

0
0
Bronze badge

Patched

Patched within a few hours of announcement, nice.

It's frightening when you think of how long it takes proprietary software vendors to acknowledge and fix bugs. Let alone how many undiscovered and undisclosed/exploited bugs must exist in proprietary software.

8
3
Anonymous Coward

Re: Patched

"Patched within a few hours of announcement, nice"

Unlike with say Microsoft where such patches would all be released at the SAME TIME as the announcement you mean?

From Open SSL Page:

"This bug fix is a successful example of what is called responsible disclosure. Instead of disclosing the vulnerability to the public right away, the people notified of the problem tracked down the appropriate stakeholders and gave them a chance to fix the vulnerability before it went public"

7
3

Re: Patched

I don't think you should be breathing a sigh of relief that it's been patched quickly, it's been in the wild for 2 years and you've practically no way of knowing whether malicious parties have been sitting on it all that time or if you've been a victim.

5
0
Silver badge

Re: Patched

>>"It's frightening when you think of how long it takes proprietary software vendors to acknowledge and fix bugs."

Sigh. There's no misfortune someone wont seize upon to push their polemnic. There's no intrinsic reason why this should get fixed any faster than a proprietary solution - indeed it was out there for two years which really just goes to show how far the "thousand eyes" falls short once software becomes complex. Ten eyes is usually nearer the mark, most of which are under so much pressure it's really no different to the same ten eyes working for a proprietary company.

This is really unfortunate and has serious consequences. On this occasion it happened with Open Source, next time it might be proprietary. But in both cases, response times can be the same. The only real difference being that discovered vulnerabilities are usually announced at the same time the fix is released, not before.

The advantage of Open Source is not magical availability of fixes or freedom from bugs. The advantage of Open Source is that it can be built on and maintained by others, meaning freedom from lock-in and project abandonment, and that you can verify it is not deliberately compromised, e.g. by a government. These are good advantages. The idea that it is inherently less prone to bugs or given to quicker patching, is PR.

7
0
Bronze badge

This will be patched in time for OpenBSD 5.5, right?

0
0
Anonymous Coward

Unlikely. 5.5 is out on May 1st and people will receive CDs before then

Source code patch is already out

I'm assuming you're talking about patching the physical media rather than having to followw -STABLE straight away

1
0

Change freeze hit in February. Note there's already an ICMP errata from March. Media are covenient but in reality you'll need to update via. STABLE build . You should be checking the errata page often

0
0
Bronze badge
Headmaster

Errata

One erratum, multiple errata.

2
0
Anonymous Coward

And this is why you cannot trust open source

Sure it's open, but if not one looks it may as well be closed.

There's no procedures to follow or quality standards to meet, so no professional audits or anything like that.

Use open source for dicking around it you must; but when it comes to the real world, you get what you pay for.

3
17

Re: And this is why you cannot trust open source

Words fail me.

Yes, we certainly need a troll icon.

1
1
Bronze badge

Re: And this is why you cannot trust open source

So let me get this straight.

You're saying that its better to pay for closed source that may have multiple unpublished vulnerabilities, and where whether published or not, its likely that you have quite a wait for patches?

How exactly is it worse to use open source where at worst a vulnerability is undiscovered/unpublished just like with closed, when at least there is a fairly good chance of an expedient patch. Not to mention should a patch not be forthcoming you have the option (if you have the skill) to fix it yourself if need be.

(Yeah I know.. don't feed the troll...)

1
1
Anonymous Coward

Re: And this is why you cannot trust open source

The thing is, to patch something you have to FIND it first. With paid software, you can pressure the company to conduct security audits and the like or threaten to move to the competition. How does one pressure the FOSS community to conduct regular, professional security audits?

2
2
Silver badge

Re: And this is why you cannot trust open source

"The thing is, to patch something you have to FIND it first. With paid software, you can pressure the company to conduct security audits and the like or threaten to move to the competition"

Oh, please ! That's worked so well with MS stuff

2
3
Anonymous Coward

Re: And this is why you cannot trust open source

"How does one pressure the FOSS community to conduct regular, professional security audits?"

By emailing them? I mean, maybe you have a direct line to Bill Gates or something but by and large multi-billionaires don't really give a toss about your concerns. What are you going to do about it? Take the money back off him?

2
1
Silver badge

Re: And this is why you cannot trust open source

How does one pressure the FOSS community to conduct regular, professional security audits?

Are you seriously suggesting that becuase something is open source, no code audits are performed, but when something is closed source, they are? I would suggest that the opposite is in fact true, and that assurances from a software house that thye have conducted such audits is not in fact verifiable, UNLESS you have access to the source code.

The fact that world renowned security experts such as Bruce Schneier disagree with you and state that "security by obscurity is no security at all," leads me to trust their opinion, rather than that of some anonymous internet commenter.

2
1
Silver badge
FAIL

Re: And this is why you cannot trust open source

Normally most of the unreasoned hatred is from over-zealous Open Source supporters attacking proprietary vendors. Thanks for doing your part today to even that out.

>>"Sure it's open, but if not one looks it may as well be closed."

Criticisms that depend on an "if something is bad, then it is bad" clause, are arguments starting from supposition and a logical fallacy. Also, you may be looking for the word "no-one".

>>There's no procedures to follow or quality standards to meet, so no professional audits or anything like that."

You're like a fish describing mountaineering. Your view of Open Source as random people throwing code at each other is staggering in its lack of familiarity with real, large Open Source projects.

>>"Use open source for dicking around it you must; but when it comes to the real world, you get what you pay for."

Actually I make a pretty good living working with Open Source software. Maybe you should "come to the real world". You'll find it's maybe moved on since you last visited.

3
0
Bronze badge

Re: And this is why you cannot trust open source

The fact that world renowned security experts such as Bruce Schneier disagree with you and state that "security by obscurity is no security at all," leads me to trust their opinion, rather than that of some anonymous internet commenter

You're misinterpreting Bruce Schneier here to bolster your case. He did not say that closed source is not secure. What he said is relying on obscurity for security purposes is not secure. There is a difference - a very big difference.

As it happens, Schneier confirmed after the Snowden revelations that he primarily uses Windows himself....

0
0

Not exactly...

"This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content"

This is a little misleading. There's no GUARANTEE that private keys were compromised, although it's possible (and should be assumed as a precaution). It just all depends on what happened to be in the memory location that was leaked. However, statistically the number of instances where this is true is going to be much smaller than the ones where it is not.

1
0
Silver badge

Re: Not exactly...

I think what they meant was "it compromises the presumed privacy of private keys". That is, it's a compromise of a feature of the protocol, not necessarily of any given piece of secret data.

As for the probability that a private key will be leaked by Heartbleed: It really depends on a particular binary running on a particular platform, and often on a particular instance of a particular binary running on a particular platform. The amount of data an attacker can get may be less than 64KB, if the overrun hits an unmapped page. If it doesn't, then it depends on whether malloc1 happened to allocate a TLS protocol buffer close enough to an EVP_PKEY structure.

The problem with the probabilistic argument is that there's no way to know if a vulnerable system has ever leaked critical data in the past. You can test your server now, and it might only expose innocuous data, but on the Nth previous run happen to have put that EVP_PKEY right near the overrun buffer.

And if, say, a vulnerable server does leak its private key, it's easy for an attacker to determine that using automated, parallelizable scans. (Basically, just test every byte string of the appropriate length to see if it's the private key corresponding to the public key in the server's certificate. You can use some heuristics to reduce the work required somewhat, too, though in a case like this it's just as easy to throw more hardware at it; you can do a lot of RSA key checks with a GPU farm.)

So the available threat models basically boil down to "assume my private key has been compromised" and "assume my private key hasn't been compromised", if you're running an Internet-facing vulnerable server. There's just no good way to narrow it down more than that, unless you keep extremely detailed logs.

1Assuming you haven't replaced your system's C implementation's malloc as the allocator for OpenSSL.

1
0
Anonymous Coward

Isn't it ironic...

OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable

OpenSSL 1.0.1g is NOT vulnerable

OpenSSL 1.0.0 branch is NOT vulnerable

OpenSSL 0.9.8 branch is NOT vulnerable

1
0
Silver badge

Re: Isn't it ironic...

Huh?

Either I've missed something, or you're from the Alanis Morissette school of irony.....

5
0
Silver badge

Re: Isn't it ironic...

I too fail to see anything ironic about it. There are only a handful of official releases in the 1.0.1 stream: 1.0.1c - 1.0.1f, and now 1.0.1g, which was just released on 7 April specifically to address this bug. Releases prior to 1.0.1c don't support TLS Heartbeat, because it's a relatively new TLS option.

Oh, and Jamie Jones: There is nothing wrong with Alanis Morissette's understanding of irony; armchair pedants who think there is clearly don't know what irony is. Irony is one of the four master tropes, and describes any case where expectations are violated, including expectations of the speaker, expectations of the audience, and expectations of convention. Most of Morrisette's examples are of the last category. HTH.

In this case, it's hard to see what expectations might be violated by a list of which OpenSSL releases are vulnerable to this bug, particularly for an observer with any experience in the software industry.

1
1
Silver badge
Happy

Re: Isn't it ironic...

"Oh, and Jamie Jones: There is nothing wrong with Alanis Morissette's understanding of irony; armchair pedants who think there is clearly don't know what irony is."

Now, that's ironic!

I'm not implying that any old random URL posed is somehow authoritive, but this one is accurate:

http://fgk.hanau.net/articles/ironic.html"

0
1

This post has been deleted by a moderator

Silver badge

"but they'll just hide under an obscure rock..... errrrrr moniker..."

Unless they constantly change their name we will at least know who they are, their posting history and particularly how many of them there are - in the case of the AC in question just one I imagine.

0
1

Honest mistake, surely - right? I'll go get more tin foil.

0
0
FAIL

Reg doesn't seem to get the implications of this bug.

You're going to follow up on this story, right Reg? This report doesn't seem to properly appreciate the magnitude of this issue - namely that (unless websites have been using Perfect Forward Secrecy) - if a malicious 3rd party has exploited the HeartBleed bug and (without any risk of discovery) dumped the server's memory and stolen the private key, they can decrypt *ALL PRIOR* communications which the attacked server engaged in with that key (even comms from when before the HeartBleed bug was introduced onto that server), if the attacker has a copy of such.

I would expect a competent security paper to give us some additional information about when and how the bug was introduced to the SSL source code (go look at a source-code repo somewhere) and, in view of the post-Snowden thing, some reasonable representation about whether it was deliberately introduced by a lackey of the intelligence community. This news is huge, and your article is distressingly brief/wrong about it.

5
0
Silver badge

Re: Reg doesn't seem to get the implications of this bug.

"dumped the servers memory"

Only if the server memory is 64K.

Whilst this is a hole, it's not, as I understand it, a huge one. Yes, keys can be compromised, but only if they are in that 64k at the time of the attack. That's quite unlikely, although not impossible, so perhaps not a world ending issue, but still an important one.

0
0
Silver badge

Re: Reg doesn't seem to get the implications of this bug.

>>"Whilst this is a hole, it's not, as I understand it, a huge one. Yes, keys can be compromised, but only if they are in that 64k at the time of the attack. That's quite unlikely, although not impossible, so perhaps not a world ending issue, but still an important one."

Your statement is correct, but incomplete. What you do after running the attack once, is then run it again. And again. And again. The danger of this attack is proven. It happens at a very low-level and there's nothing to stop an attacker running a quick dozen probes and getting a whole heck of a lot more than 64K. In fact, that's how one of the firms demonstrated the vulnerability.

4
0

Re: Reg doesn't seem to get the implications of this bug.

From heartbleed.com:

Can attacker access only 64k of the memory?

There is no total of 64 kilobytes limitation to the attack, that limit applies only to a single heartbeat. Attacker can either keep reconnecting or during an active TLS connection keep requesting arbitrary number of 64 kilobyte chunks of memory content until enough secrets are revealed.

1
0
Silver badge

Re: Reg doesn't seem to get the implications of this bug.

I would expect a competent security paper to give us some additional information about when and how the bug was introduced to the SSL source code (go look at a source-code repo somewhere)

Have at it:

http://cvs.openssl.org/chngview?cn=21899

(This change was made before OpenSSL switched to git.) Down near the bottom you'll find the source for tls1_process_heartbeat (there's an equivalent function for DTLS, but really - DTLS? bah!). The bug is obvious in retrospect, IMO, though I think it'd be a lot easier to see if the OpenSSL source base did not continue the very unfortunate tradition of abysmally short and nearly meaningless variable names that infects so much C code. (Watch the variables "pl" and "payload".)

Change submitted by Robin Seggelmann <seggelmann@fh-muenster.de>. I suppose he might be a covert NSA agent, but that seems like a bit of a stretch. This looks like a common-or-garden dumb bug to me.

Indeed, in the annals of dumb SSL/TLS implementation bugs, I think this ranks as less embarrassing than the recent GnuTLS bug, and arguably than the recent Apple bug. I'd even call it less embarrassing than the RSA BSAFE-defaults-to-Dual_EC_DRBG issue, because it appears to be an honest mistake rather than incompetence, which is the kinder interpretation of the RSA fuckup.

We're running out of SSL/TLS implementations that haven't had an embarrassing flaw documented this year. What's left? Microsoft's, Certicom's... I'd be nervous if I were in their shoes. The researchers are on a tear.

1
0
Silver badge

Re: Reg doesn't seem to get the implications of this bug.

We're running out of SSL/TLS implementations that haven't had an embarrassing flaw documented this year.

And RSA just announced a new one in RSA BSAFE (on Bugtraq; it's CVE-2014-0636, but that CVE is still listed as "reserved" with no info). Apparently this time it's a bug in certificate chain processing that "might incorrectly allow conversations" that should be rejected - in other words, failing unsafe with invalid authenticators in some cases. So equivalent to the GnuTLS bug in severity (worse than the Apple one, not as bad as the OpenSSL one), though currently we don't know anything about the frequency, or how hard it is to exploit.

As always, the devil is in the implementation. And the implementations are all broken.

1
0
This topic is closed for new posts.

Forums