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 Coder: Bug In OpenSSL Was an Honest Mistake

samzenpus posted about 4 months ago | from the only-human dept.

Security 447

nk497 (1345219) writes "The Heartbleed bug in OpenSSL wasn't placed there deliberately, according to the coder responsible for the mistake — despite suspicions from many that security services may have been behind it. OpenSSL logs show that German developer Robin Seggelmann introduced the bug into OpenSSL when working on the open-source project two and a half years ago, according to an Australian newspaper. The change was logged on New Year's Eve 2011. 'I was working on improving OpenSSL and submitted numerous bug fixes and added new features,' Seggelmann told the Sydney Morning Herald. 'In one of the new features, unfortunately, I missed validating a variable containing a length.' His work was reviewed, but the reviewer also missed the error, and it was included in the released version of OpenSSL."

cancel ×

447 comments

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

It goes to show that... (4, Insightful)

marciot (598356) | about 4 months ago | (#46720699)

Coding and campaign do not mix.

Names! (0)

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

We know the coder, we don't know the reviewer.

Re:Names! (4, Informative)

bloodhawk (813939) | about 4 months ago | (#46720799)

The reviewer was named too.Dr Stephen Henson

Re:Names! (4, Informative)

grub (11606) | about 4 months ago | (#46720933)

PR: 2658

Submitted by: Robin Seggelmann <seggelmann@fh-muenster.de>
Reviewed by: steve

Support for TLS/DTLS heartbeats.

Have a look for yourself. [github.com] The reviewer "steve" is Stephen Henson.

Whatever you may think ... (5, Interesting)

Kittenman (971447) | about 4 months ago | (#46720709)

hats off to the developer who admits a mistake.

I suspect s/he'll get pilloried in the press and may end up with some lawsuits (?) but I, for one, recognize a person big enough to take responsibility.

Re:Whatever you may think ... (2, Informative)

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

The RFC and the Git commit both have his name firmly attached to the "feature". He hasn't admitted anything that wasn't proven already.

Re:Whatever you may think ... (0)

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

hats off to the developer who admits a mistake. .

and what exactly was his other option? It was either a mistake or intentional, admitting it was a mistake is the least evil explanation he can get away with (I actually believe him but regardless there really was no other explanation that would cause him less pain).

Re:Whatever you may think ... (5, Insightful)

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

may end up with some lawsuits (?)

very difficult;

a) the license clearly states the lack of warantee

b) the source code is available so you could have audited if you want

c) I for one will contribute considerably if that happens unless decent evidence is uncovered that he works for the NSA. I'm sure there are several others who will do the same.

Re:Whatever you may think ... (0, Flamebait)

glasshole (3569269) | about 4 months ago | (#46720927)

considerably

A few $100 won't save anyone from the US justice machine. CHOO CHOO

Re:Whatever you may think ... (-1)

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

c) I for one will contribute considerably if that happens unless decent evidence is uncovered that he works for the NSA. I'm sure there are several others who will do the same.

So you'll contribute your entire $20 allowance? Hoooo boy!

Re:Whatever you may think ... (4, Insightful)

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

Devil's advocate here: I have to thank the developer for even working on OpenSSL. I fear that the bad press and consequences coming down on these developers will scare more people off from core OSS projects and we will end up with more app developers on smartphones instead of infrastructure improvements.

It would be nice if they had some sort of code review in place for this sort of stuff. However, this isn't a paid project, so the developers writing this are doing arguably the best they can.

Re:Whatever you may think ... (1)

ThatsMyNick (2004126) | about 4 months ago | (#46720909)

Well, he hasnt admitted to anything. He has two options 1) Admit it was malicious 2) Admit it was a mistake. It doesnt take a genius to figure out 2 is the best option.

Re:Whatever you may think ... (5, Insightful)

musmax (1029830) | about 4 months ago | (#46721173)

No he has many more options than that. He did not need to respond at all, he does not need answer to anyone or is liable for anything, read the licence. If it was me and I was inclined to comment at all, I would just say: "Well shit, fuck me for trying. If you think you can do better - please do."

Re:Whatever you may think ... (1)

ThatsMyNick (2004126) | about 4 months ago | (#46721257)

Everyone already knew it is one of those two. Responding and choosing the easiest option doesnt take courage or make him any more liable. It would actually reduce liability. I agree he is not hiding, but he is being smart. A few words can save him a lot of trouble and lot of pestering by the media. If it was me (and I indeed made a mistake, or I had malicious intentions), I would have done the same. Not because I am courageous or anything, because that is the safest thing to do, right now.

Re:Whatever you may think ... (5, Insightful)

im_thatoneguy (819432) | about 4 months ago | (#46720935)

Boy, if there's one thing that could ever kill Open Source it would be being held legally liable for a commit with a bug in it.

Which is why all projects are released AS-IS without any liability.

Re:Whatever you may think ... (-1)

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

Which is why all projects are released AS-IS without any liability.

Which does not mean that a court of law will uphold it. I can put a sign on my car disclaiming myself from liability from hitting you. Doesn't mean it has any legal weight behind it.

Re:Whatever you may think ... (4, Insightful)

GigaplexNZ (1233886) | about 4 months ago | (#46721261)

Totally not the same thing. These companies have the option of not using OpenSSL. In your analogy, where's my option of not getting hit by you?

Re:Whatever you may think ... (0)

Nidi62 (1525137) | about 4 months ago | (#46721385)

Totally not the same thing. These companies have the option of not using OpenSSL. In your analogy, where's my option of not getting hit by you?

Well, you chose to be sitting on your couch when he drove into your living room, didn't you?

Re:Whatever you may think ... (5, Funny)

GigaplexNZ (1233886) | about 4 months ago | (#46721479)

I didn't get to read his disclaimer prior to having my living room intruded by his vehicle so I was unable to make such an informed decision. He should have honked first.

Re:Whatever you may think ... (1)

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

I'd like you to meet my friend, Mr. Straw Man.

Re:Whatever you may think ... (5, Insightful)

grub (11606) | about 4 months ago | (#46721009)


Boy, if there's one thing that could ever kill Open Source it would be being held legally liable for a commit with a bug in it.

It burns me that RSA is not held liable for their $10M NSA backdoor in Dual_EC_DRBG PRNG. Customers should be flocking in droves but RSA gives enough swag at conferences that the suits don't care.

Your privacy sold off for $10M and some mouse pads.

Re:Whatever you may think ... (-1, Troll)

cold fjord (826450) | about 4 months ago | (#46721099)

What "backdoor" are you referring to? It has been speculated that one may be possible given the nature of the curve, but as far as I know nobody has proven that one actually exists in the fully implemented standard with correction. Do you have proof?

Re:Whatever you may think ... (4, Informative)

grub (11606) | about 4 months ago | (#46721219)


RSA has denied having knowledge of the backdoor, says NSA tricked them, and has never denied the $10M payout. Some of Snowden's leaks mention it.
Reuters has a summary [reuters.com]

proof-of-concept backdoor with a link to the github repo.

None of that is a smoking gun, but there is enough smoke to tell me there is a fire.

Re:Whatever you may think ... (3, Interesting)

grub (11606) | about 4 months ago | (#46721227)

[sorry, link screwed up in my reply, should have checked more closely.]

There is also a nice proof-of-concept backdoor [0xbadc0de.be] with a link to the github repo.

Re:Whatever you may think ... (4, Interesting)

symbolset (646467) | about 4 months ago | (#46721475)

As opposed to commercial software, which limits liability to the cost of the distribution media. That 3 centsmakes all the difference.

Re:Whatever you may think ... (0)

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

hats off to the developer who admits a mistake.

I suspect s/he'll get pilloried in the press and may end up with some lawsuits (?) but I, for one, recognize a person big enough to take responsibility.

Too bad he wasn't working on the Obamacare website. Then he'd have nothing to worry about.

Re:Whatever you may think ... (5, Funny)

Krishnoid (984597) | about 4 months ago | (#46721293)

hats off to the developer who admits a mistake.

It's laudable but insufficient; to genuinely move towards making the aggrieved parties whole, I think it demands nothing short of a full refund.

Re:Whatever you may think ... (1)

Mitchell314 (1576581) | about 4 months ago | (#46721443)

Here you go: three internets.

Re:Whatever you may think ... (2)

hydrofix (1253498) | about 4 months ago | (#46721327)

may end up with some lawsuits (?)

If you have ever wondered why all the popular open source licenses, like GPL, BSD and Apache, include the "warranty" and "limitation of liability" clauses, this is exactly why. The clauses usually state something like "this software is provided 'as is' and without any warranty. The user of the software assumes all risks that may arise. In no event shall the project or its contributors be liable for any damages."

Re:Whatever you may think ... (2)

gweihir (88907) | about 4 months ago | (#46721359)

This is not the US. There will be no lawsuits. "No warranty" actually has meaning here.

Re:Whatever you may think ... (1)

phantomfive (622387) | about 4 months ago | (#46721407)

hats off to the developer who admits a mistake.

Did he really have any other option here? Even if he did it on purpose, would he admit it?

It's not just the implementation (5, Interesting)

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

The design of the feature looks like a backdoor too. A heartbeat function with a variable length payload, and there is a superfluous field for the payload length, and all running on top of TCP, which already has a keep-alive function? And then the feature contains a "rookie mistake", but still passes review. Yes, we totally believe you. It was a mistake.

Re:It's not just the implementation (5, Informative)

grub (11606) | about 4 months ago | (#46720777)


and all running on top of TCP

Not necessarily. OpenVPN is an SSL VPN which defaults to UDP/1194.

Re:It's not just the implementation (4, Insightful)

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

The feature was TLS/DTLS heartbeats, with the "D" in DTLS standing for datagram.

HTTPS isn't the only thing using OpenSSL. As grub pointed out, OpenVPN uses it as well, and will use DTLS by default.

The advantage of tunneling traffic in datagrams is that if you try to tunnel TCP traffic within TCP, performance suffers due to dueling TCP backoff.

Re:It's not just the implementation (4, Insightful)

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

It's a possibility, but pretty paranoid reasoning.

Assuming you have coded in your life (your language implies so), there were errors. I certainly made more than a few. Some the compilers caught, some the testing, some the users, some the accountants; some... probably nobody.

Care to explain why any of yours were not intentional because it sure looks that way. Hindsight is cheap.

My knee jerk was also that length would be superfluous - from zero context and understanding of the spec/RFC. But there could be a lot of reasons. If your job is to process a formally defined struct, you are not going to review the struct in an attempt to change the standard.

Which brings us back to where we began. If this was a conspiracy, intentional coding would be required for exploit. Given that, I find it difficult to accept that an agency intentionally first complicated the spec by including a length field (which *could* be checked, in the name of security, for protocol robustness rather than local memory ops); then hen perverted a particular implementation in a manner that looks exceedingly garden variety. Easier to never have the length field in the first place.

He's sorry now ... (0)

drnb (2434720) | about 4 months ago | (#46720741)

He's sorry now, wait until some lawyer shows up on his doorstep with a bill.

Re:He's sorry now ... (2, Informative)

viperidaenz (2515578) | about 4 months ago | (#46720833)

Lawyers love EULA's and licenses. The OpenSSL license disclaims all liability

* THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
  * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
  * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
  * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
  * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
  * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
  * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
  * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
  * OF THE POSSIBILITY OF SUCH DAMAGE.

https://www.openssl.org/source... [openssl.org]

If you never agreed to that license, you're violating their copyright.

Re:He's sorry now ... (0)

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

It would be an interesting case. In most cases a EULA isn't worth the virtual paper it is written on when it states you aren't protected negligence, consumers have a lot of rights that cannot be signed away in a lot of states and countries regardless of what the license says.

Re:He's sorry now ... (1)

elfprince13 (1521333) | about 4 months ago | (#46721383)

Sure, but what's the case law on the application of consumer-rights to free stuff?

Re:He's sorry now ... (-1)

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

Lawyers love EULA's and licenses. The OpenSSL license disclaims all liability

You can't disclaim negligence. It's the same reason why those dump trucks that have signs on them trying to claim they aren't liable for damaging other vehicles have no legal force behind them.

If you never agreed to that license, you're violating their copyright.

If terms of the license violate the law, the terms have no legal binding.

Re:He's sorry now ... (1)

zekele2 (1556449) | about 4 months ago | (#46721149)

posting to undo moderating error, please ignore...

Re:He's sorry now ... (1)

GigaplexNZ (1233886) | about 4 months ago | (#46721317)

This is the second example I've seen in this thread where disclaiming negligence for vehicular accidents is compared to disclaiming negligence for software bugs on an unpaid open source project that companies aren't obligated to use.

And even if these companies could legally sue (jurisdictions notwithstanding), what would the point be? This is an individual with limited funds - they'd bankrupt him but wouldn't get enough from him to cover their legal fees.

Re:He's sorry now ... (1)

bloodhawk (813939) | about 4 months ago | (#46721405)

while the comparison between cars and software is ridiculous. Many places do not permit a EULA or any other agreement to sign away a persons rights to protection from negligence regardless of what the product is, such clauses can be deemed invalid.

Re:He's sorry now ... (1)

GigaplexNZ (1233886) | about 4 months ago | (#46721469)

I'm sure there are many places that don't permit such a EULA, however are they the jurisdiction where he wrote and published the code? (honest question - I don't know) Jurisdiction matters for such things, which is how some open source projects get away with code that infringes patents in some regions but not others for example.

Re:He's sorry now ... (1)

JeffAtl (1737988) | about 4 months ago | (#46721417)

The point is that you disclaimers are not always legally binding. The vehicular examples are just examples that many people may find familiar. You're reading too much into them.

Regardless, I agree that he is safe legally. It's not the disclaimer that protecting him though.

Sue FSF, relicense all GNU software ... (1)

drnb (2434720) | about 4 months ago | (#46721491)

And even if these companies could legally sue (jurisdictions notwithstanding), what would the point be?

Take ownership and control of the project.

Hmmm ... Find a way to sue the FSF, get ownership/control, relicense all GNU software.

Linux and Security (0)

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

As Linux grows, so will the bugs, exploits, and vulnerabilities.

Don't know much about what and how but many major corporations are struggling to figure out what the risks are and how to remediate.

It is going to be a busy month and a log of developers coders and qa people will be very busy...

Re:He's sorry now ... (0)

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

It doesn't work like that outside the US... Especially not in the EU.

Doesn't seem to be on purpose (1)

anth (2631) | about 4 months ago | (#46720747)

Even the NSA wouldn't cause a disaster of this magnitude just to spy on everyone.

Re:Doesn't seem to be on purpose (0)

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

Even the NSA wouldn't cause a disaster of this magnitude just to spy on everyone.

He's in Germany. That would be more Russian FSB territory (formerly KGB and Stasi territory).

Re:Doesn't seem to be on purpose (0)

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

For the record: Germany has plenty of both: ex-stasi and still-USA.
Also still-USA are still-there, while stasi formally is over by twenty years or so.

Re:Doesn't seem to be on purpose (1)

cold fjord (826450) | about 4 months ago | (#46721121)

You left out the Russia's FSB, and the intelligence services of China, Iran, and many others.

Re:Doesn't seem to be on purpose (0)

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

I want some of what you are smoking.

Re:Doesn't seem to be on purpose (1)

HatofPig (904660) | about 4 months ago | (#46720897)

The NSA couldn't know that some foreign powers wouldn't quickly discover the bug as well and start hacking major US corporations that were vulnerable. They wouldn't even have been able to detect it was happening unless they made some honeypot which, if discovered, would have implicated them further. The risk is way too great.

Re:Doesn't seem to be on purpose (0)

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

The NSA doesn't care about foreign powers, they are not a threat to their funding. The NSA wants to make sure they can keep all those pesky American's under their thumb.

In fact, from the Snowden leaks, we know the NSA has put back doors in all sorts of things that foreign powers could easily discover.

Re:Doesn't seem to be on purpose (1)

JeffAtl (1737988) | about 4 months ago | (#46720997)

Russia now has full access to any of those back doors.

Re:Doesn't seem to be on purpose (2)

cusco (717999) | about 4 months ago | (#46721137)

They always did, the US and British intel agencies have always been double-agent ridden. I doubt that much of what Snowden revealed was a surprise to Moscow.

Re:Doesn't seem to be on purpose (0)

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

Even the NSA wouldn't cause a disaster of this magnitude just to spy on everyone.

Yes they would. They're one of the few organizations on the planet that has a significant archive of pre-exploit-going-wild traffic.

Now we see one of the reasons why they archive such traffic: just in case a screwup like this comes to light (and/or because they were already aware of it and didn't tell anyone). In a pre-PFS era, an archive of every SSL session going back to (REDACTED) can be pretty useful, because someday, hopefully before the disk fills up, you or somebody else might discover a way to obtain or derive the keys that will decrypt large portions of those archived encrypted sessions.

I don't know whether or not NSA was behind this. I do believe that if they knew about it, they acted against the interests of information assurance by not helping American companies affected by the vulnerability in addressing it.

But then, for all I know, everybody who did IA at NSA has been fired, shot, disappeared, or otherwise compromised. Once upon a time, NSA helped Americans secure their communications, and could be somewhat trusted to do so. Even if they changed their policy 180 degrees, it will be at least 20 years before American corporations can trust them to do so again.

Re:Doesn't seem to be on purpose (1)

JeffAtl (1737988) | about 4 months ago | (#46721039)

How did this get turned into a NSA thread?

Re:Doesn't seem to be on purpose (0)

cold fjord (826450) | about 4 months ago | (#46721145)

Every story / thread is a potential NSA thread these days. It is the current fashion in the fever swamps. .

Re:Doesn't seem to be on purpose (3, Insightful)

TheGratefulNet (143330) | about 4 months ago | (#46721275)

we do it just to bug YOU, cold fnord.

we know it pisses you off to have your boys look bad.

DEAL WITH IT. or just leave. either is fine with most of us.

Re:Doesn't seem to be on purpose (0)

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

Are we now pretending like the NSA doesn't have a history of subverting critical systems related to the flow of encrypted communications?

Improving? (0)

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

If adding features ever improves software it is usually only for a tiny percentage of users. Mostly it just introduces vulnerabilities like this and soaks up cpu cycles and disk space. Of course we have to have progress or coders would get awfully bored doing nothing but fixing bugs and improving performance. Still it surprises me that security software can be modified so quickly and with only one review. If you want to add a feature to anything as critical as SSL, it should be reviewed and tested by numerous experienced coders over a period of many months.

Re:Improving? (1)

GigaplexNZ (1233886) | about 4 months ago | (#46721331)

Still it surprises me that security software can be modified so quickly and with only one review

It's an open source project, who's going to stop them writing the code and making it available?

ya ya.. (0)

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

I missed validating a variable containing a length

right.

on purpose or not, couldn't happen if... (2, Interesting)

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

All I know is the organization I work for has prohibited use of C or C++ for mission critical software for years now. The languages we use would not ALLOW code to execute which tries to copy 64K from a 2 byte sized container.

Part of software engineering is to use the right tool for the right job. When a buffer overrun can destroy the security of the entire internet, you damn well better not be using C as your tool. Or assembly language for that matter.

Do that where I work, and you'd be fired.

Re:on purpose or not, couldn't happen if... (0)

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

Out of curiosity, what language would you use?

Re:on purpose or not, couldn't happen if... (1)

cold fjord (826450) | about 4 months ago | (#46721157)

I'm going to bet Java or Ada.

Re:on purpose or not, couldn't happen if... (0)

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

I totally agree. We should code whole operating systems in HTML so we know for sure this kind of issue never happens again! ...Or, we can see it for what it is, and use the tools available to us responsibly. It's not exactly very hard to prevent that issue in C/C++, and the guy taking responsibility for this bug went out of his way to avoid protections.

Re:on purpose or not, couldn't happen if... (1)

GigaplexNZ (1233886) | about 4 months ago | (#46721351)

All I know is the organization I work for has prohibited use of C or C++ for mission critical software for years now. The languages we use would not ALLOW code to execute which tries to copy 64K from a 2 byte sized container.

C++ has bounds-checked containers.

Re:on purpose or not, couldn't happen if... (2)

gweihir (88907) | about 4 months ago | (#46721377)

This is BS. You can screw up just as badly in any other language. It will just be less obvious. Of course, the combination of an incompetent code writer and an incompetent reviewer will quite often have spectacularly bad results.

code review idea (1)

onepoint (301486) | about 4 months ago | (#46720881)

Well, maybe this is a blessing. While it's open source, maybe multiple eye's need to look at it for final validation.
While never have worked with open source, I do work with data very often. I re-validate entries a lot and just scan data look for something odd. I am amazed at the amount of errors I find, so I report them and go from that point onwards.
sometimes I work with teams of people and have a kind of race looking to find the most errors, then we go out and the winner only buys 1 round, and does not pay the bill for dinner.

Well, his software career's ruined (-1, Troll)

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

There's no coming back from such a serious widespread bug like this. He'll be blacklisted for virtually all decent software development jobs from now since his name will be spread far and wide for this blunder. Which I think is unfair, given such bugs are supposed to be detected by a third party before incorporation (like an editor), but given the reviewer missed it as well, the rest is history.

Now he'll be relegated to solely open-source work - the lowest of the low.

Re:Well, his software career's ruined (-1)

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

Why the fuck was this modded -1? I suspect if he didn't put in that last line it would either have stayed at 0 or gone higher, but no, because some freetards can't handle a bit of reality thrown their way now and then, it gets modded a troll regardless of the content of the rest of the post. Motherfucking idiots the whole lot of ya.

for a library... (5, Insightful)

MarcoAtWork (28889) | about 4 months ago | (#46720955)

... so much of the internet depends on for security just one reviewer for a commit seems way way way too little, honestly checking anything into openssl (or gnutls) should be at least a 4-step approval process (submitter -> mantainer for that area -> overall library mantainer -> security officer), for any code that includes buffers/malloc especially if related to user supplied data the final security review should be a panel.

Everybody makes mistakes, everybody can have a 'brown paper bag' coding moment (especially around Christmas/New Year's like it happened in this case), 2 people having a 'brown paper bag' moment at the same time around the holidays is definitely not that unlikely, for something as important as a crypto library on which so many things depend a single reviewer is just not enough.

I do feel for the original developer, and hope that he won't suffer more about this than he already is (any developer worth their salt feels quite bad about bugs they introduce, let alone if they lead to this many problems), we've all made coding mistakes, no matter how experienced we are, so the focus should not be on "who" but more on "what kind of process can we introduce so this does not happen again".

Moving away from C in my opinion would just be a band-aid, other languages don't expose you to this particular bug, that's fine, however for security software choosing a vetting process for what goes in the codebase is a lot more important than choosing what language it's written in, not to mention that it's not that "hard" to write "secure C" especially if one leans on all the various available tools/libraries and writes proper unit tests, in this case for example had the malloc decision not been influenced by performance reasons (on unspecified platforms) this would not have been as big of a deal as it was.

Re:for a library... (4, Insightful)

MightyMartian (840721) | about 4 months ago | (#46721051)

Moving away from C just means you now have to have faith in some bytecode virtual machine's memory and buffer management. Is it a more secure approach? Maybe, but if the root complaint is putting faith in complex software, coding in Java or some .NET language means trusting the people coding those engines are equally capable of screwing up. All these higher level virtual machines and interpreters are ultimately written in C.

Re:for a library... (2)

GigaplexNZ (1233886) | about 4 months ago | (#46721375)

Moving away from C just means you now have to have faith in some bytecode virtual machine's memory and buffer management. Is it a more secure approach? Maybe, but if the root complaint is putting faith in complex software, coding in Java or some .NET language means trusting the people coding those engines are equally capable of screwing up. All these higher level virtual machines and interpreters are ultimately written in C.

Or you could just use C++ complete with their bounds-checked containers.

Re:for a library... (0)

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

Visual inspection of anything, including code, is only ~85% effective. You need 6 passes to reach .9999 reliability.
Robust test suites can help here, but I'd agree a couple more reviewers need to be engaged.

Re:for a library... (0, Troll)

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

Welcome to the bullshit that is OSS.

Just because everyone can look at the code, doesn't mean anyone IS looking at the code.

Re:for a library... (5, Insightful)

phantomfive (622387) | about 4 months ago | (#46721455)

Just because everyone can look at the code, doesn't mean anyone IS looking at the code.

Security is only one good reason to have the source code. Another very big convenience for programmers is the ability to figure out what went wrong when a library returns a bug.

Furthermore, no one ever said open source was perfect, just that it was better than proprietary code. And that is probably true; the worst open source code I've seen is much better than the worst proprietary code I've seen.

Re:for a library... (1)

phantomfive (622387) | about 4 months ago | (#46721437)

... so much of the internet depends on for security just one reviewer for a commit seems way way way too little, honestly checking anything into openssl (or gnutls) should be at least a 4-step approval process (submitter -> mantainer for that area -> overall library mantainer -> security officer), for any code that includes buffers/malloc especially if related to user supplied data the final security review should be a panel.

In my experience, adding extra reviewers who look at the code gives diminishing returns after the first review.

To improve security, the first thing I would do is add an independent QA coder who would write tests for every single line of code. I don't think many people would want to volunteer their time being a QA coder, but that's what I think would be most effective.

Moving away from C in my opinion would just be a band-aid, other languages don't expose you to this particular bug,

The ironic thing is, in the last 5 years, I've seen more memory leaks go into production from Java code than from C code.

I don't believe him (0)

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

He and the reviewer that ok'd his code submission should be brought in for questioning.

Re:I don't believe him (1)

MildlyTangy (3408549) | about 4 months ago | (#46721265)

I don't believe him. He and the reviewer that ok'd his code submission should be brought in for questioning.

You are totally correct. As it is "you" who does not beleive him, governments of the world should work together to bring this man and his reviewer in for questioning.

This is now a matter of urgent and International importance.

Hurry before its too late! AC has spoken!

Bigger problem: stupid 'optimizations' (3, Interesting)

Bram Stolk (24781) | about 4 months ago | (#46721019)

The bigger problem is coders that think they need to optimize for speed.
Read the horror here: http://article.gmane.org/gmane... [gmane.org]

Ugh... premature optimization, the root of all evil. And now also the root of the biggest security hole ever.

Re:Bigger problem: stupid 'optimizations' (0)

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

Performance for OpenSSL is very important, so I'm not sure why you would be critical of the desire to optimize. And while premature optimization is certainly a bad idea, do you have any proof (or even evidence) that that is what happened here? It is entirely possible that they profiled and found that they could improve performance by writing their own allocator.

Re:Bigger problem: stupid 'optimizations' (2)

swinefc (91418) | about 4 months ago | (#46721309)

While I agree with you about premature optimization, stop and think for a minute how many trillions of trillions this one bit of code has executed. If you do the math (left for the reader), then there is a real world cost to not optimizing this code. Electricity and time usage are affected.

Re:Bigger problem: stupid 'optimizations' (1)

GigaplexNZ (1233886) | about 4 months ago | (#46721379)

It was a feature addition, not a performance optimisation, that added this bug.

Re:Bigger problem: stupid 'optimizations' (1)

gweihir (88907) | about 4 months ago | (#46721393)

Indeed. This was not just one screw-up, it is the end-result of quite a chain of them. You can optimize for speed, but it is an expert's game. Far to many coders believe they are experts when they do not even come close.

Why is he even excusing himself ? (5, Insightful)

musmax (1029830) | about 4 months ago | (#46721093)

He has no reason to. He gave it a best effort shot given the resources. If you can do better, fucking do it.

Re:Why is he even excusing himself ? (5, Insightful)

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

Thank you for a bit of sanity. What you wrote should be the summary text for every article on the subject: "He gave it a best effort shot given the resources. If you can do better, fucking do it."

As an open-source dev myself, I often wonder why the fuck I do anything useful for others when they'll just turn on me the moment their toys don't work exactly as desired because -- gorsh -- I'm not perfect, though I work very hard to be.

Re:Why is he even excusing himself ? (0)

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

+5 and then some.

not a single mistake, symptom of bigger problem (2, Interesting)

iggymanz (596061) | about 4 months ago | (#46721131)

Re:not a single mistake, symptom of bigger problem (2)

gweihir (88907) | about 4 months ago | (#46721423)

Indeed. While both this person and the reviewer messed up badly and their competence is rightfully in question, they were also set-up by omission of basically everything you need to do to produce secure code in OpenSSL and by sabotage (likely due to terminal stupidity) of safeguards that _were_ available.

To produce a catastrophe, several people have to screw up spectacularly. This is what happened here. Quite often, when you dig down, you find a combination of big egos and small skills.

Sloppy code (5, Informative)

billrp (1530055) | about 4 months ago | (#46721161)

I glanced at some of the OpenSSL C code, in particular the new code that introduced this bug. No comments, no asserts, no cross-checks, stupid variable names (like "payload" for the size of the payload, "pl" for a pointer to the payload data), no suggestions for how to test this new feature (such as what if the request has the payload size field that's not the same as the actual payload). In an unrelated function I saw an array declared on the stack, getting filled up, and then a pointer to this array getting assigned to a field of an argument to this function, and then a return...

Re:Sloppy code (2, Interesting)

musmax (1029830) | about 4 months ago | (#46721209)

I'm sure the project will appreciate your patches.

Re:Sloppy code (0)

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

Blah, blah, blah...

OpenSSL is free software. Do better or shut up and let those who can work in peace.

Re:Sloppy code (1)

GigaplexNZ (1233886) | about 4 months ago | (#46721421)

In an unrelated function I saw an array declared on the stack, getting filled up, and then a pointer to this array getting assigned to a field of an argument to this function, and then a return...

Seriously? What function?

Re:Sloppy code (0)

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

In an unrelated function I saw an array declared on the stack, getting filled up, and then a pointer to this array getting assigned to a field of an argument to this function, and then a return...

Seriously? What function?

void ssl_ruinTheInterwebs()

lesson (1)

Swampash (1131503) | about 4 months ago | (#46721165)

Never stay up rushing commits on New Year's Eve.

Credentials (0)

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

I had to post anonymously because I was not sure my credentials are safe on this site

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

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>