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

cancel ×

239 comments

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

what? (5, Insightful)

Anonymous Coward | about 4 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 4 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."

Fuck Beta (-1)

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

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

Thank you for the mess (4, Insightful)

manu0601 (2221348) | about 4 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 4 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 4 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 4 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 4 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 4 months ago | (#46710161)

Midnight_Falcon, you are indeed a rare bird. :)

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

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

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

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

ras (84108) | about 4 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 (3, Insightful)

phantomfive (622387) | about 4 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 (1)

Kittenman (971447) | about 4 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 ...

Is OpenVPN affected? (1)

manu0601 (2221348) | about 4 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 4 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 4 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 4 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.

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

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

nt

IDS != Remedy (2)

AcerbusNoir (1257586) | about 4 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 4 months ago | (#46710329)

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

Re:IDS != Remedy (1)

viperidaenz (2515578) | about 4 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 4 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 4 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 4 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 4 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? (1)

ArchieBunker (132337) | about 4 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 4 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 4 months ago | (#46710795)

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

it's all over (1)

turkeydance (1266624) | about 4 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 4 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.

Mountain out of a molehill (0)

dreamchaser (49529) | about 4 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 4 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 4 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 4 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 4 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 4 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 4 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 4 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 4 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 (0)

Anonymous Coward | about 4 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 4 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 (4, Informative)

Anrego (830717) | about 4 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 (5, Interesting)

kiite (1700846) | about 4 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 (0)

Anonymous Coward | about 4 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 4 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 4 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 4 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 4 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 4 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.

Situation is a Shambles (5, Insightful)

ObsessiveMathsFreak (773371) | about 4 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 4 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 4 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 4 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 4 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 4 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 4 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 4 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.

Beta Sucks (0)

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

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

Re:Situation is a Shambles (0)

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

Easier: Unit test before releasing things.

Coding Style versus Language (5, Insightful)

nanolith (58246) | about 4 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 4 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 4 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 4 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 4 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:Coding Style versus Language (0)

Anonymous Coward | about 4 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 4 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 4 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:Situation is a Shambles (1)

Fnord666 (889225) | about 4 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 4 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 4 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 4 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 (0)

Anonymous Coward | about 4 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 (0)

Anonymous Coward | about 4 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 4 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 4 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 4 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 (1)

CODiNE (27417) | about 4 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 4 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).

Hmmm (1)

koan (80826) | about 4 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 4 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 4 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 4 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!

OSX not affected? (1)

DaveyJJ (1198633) | about 4 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 4 months ago | (#46710421)

Phew. At least 2 websites are safe!

Re:OSX not affected? (1)

rubycodez (864176) | about 4 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 4 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 4 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 4 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 4 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 4 months ago | (#46710447)

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

rubycodez (864176) | about 4 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 4 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 4 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 4 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 4 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.

FreeBSD 8.2 and openssl-0.9.8 FTW (0)

Anonymous Coward | about 4 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 4 months ago | (#46710771)

your popular PHP5 platforms will be so safe on that

Tax Office Closed (1)

Anonymous Coward | about 4 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 4 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 4 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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>