'Heartbleed' contributor denies he inserted it deliberately • Hacker News Board

Re: 'Heartbleed' contributor denies he inserted it deliberately

#41

Post by nikcub » Thu, Apr 10, 2014, 3:09 PM UTC

krstck wrote: post #13

It we start naming and shaming the coder for each flaw instead of working on fixing the process that allowed it to sneak through, we'll see a chilling effect on open source software. There's a reason we have tests and code reviews and security audits...

I just happen to be speaking to the very reporter who wrote this article prior to him publishing this report. I told him that in 'our world' we don't really emphasize or make much of who introduced the bug, since it is understood that writing secure code is hard.

But what required the denial from the developer (and I feel horrible for him) is that this bug gained so much mainstream attention and speculation. It was only a matter of time before a reporter wanting to further the story got in touch with him.

He was in a bad situation - don't respond and have that misconstrued or respond and deny and give credence to the theory.

We all know that he didn't do it intentionally and in absence of any supporting evidence in all cases these are simple mistakes, but the general public who are currently whipped up in a frenzy around NSA revelations don't know that.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#42

Post by JPKab » Thu, Apr 10, 2014, 3:10 PM UTC

I work with both private and public sectors in the DC area.

One of the things that sucks about the Federal sector is that they are dominated by Microsoft and Oracle shills (the kind of IT pros who can't learn new skills unless its spoon fed pre-digested in the form of industry certification training) who do nothing but scream about the danger of open source. Now of course we all know that the only difference between enterprise and open source security holes is that the former go undiscovered for longer, and when discovered by the code owners aren't disclosed despite them having knowledge that black-hats know about it.....

But make no mistake. This fucking idiot [Edit: Ok, this isn't fair, this could happen to anyone, so he's not an idiot, but why not use a static analysis tool?] who did this to OpenSSL and the idiots who let it happen are going to set open source in the Federal government back YEARS. Not because its an actual threat, but because it will be used by the enterprise assholes as a weapon to keep selling their shitware to the risk averse morons who make up the giant pile of middle manager idiots that composes the Federal government.

I've already told my boss I'm not doing any more public sector work after my current project ends, and this is the nail in the coffin for me touching it ever again.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#43

Post by sp332 » Thu, Apr 10, 2014, 3:10 PM UTC

nikcub wrote: post #33

notacoward wrote: post #29

Maybe the silver lining here is that it puts the final nail in the coffin for "many eyes make all bugs shallow" - which was always total BS from the day it was uttered. There's so much code out there, much of it highly specialized and even project-specific, that there are very few eyes looking at any particular piece of code, and not all eyes are connected to the greatest of brains. Most static code analyzers could h…

> Maybe the silver lining here is that it puts the final nail in the coffin for "many eyes make all bugs shallow" The OpenSSL project doesn't seem to have a 'review' step[0] in code commits, unlike FreeBSD, OpenBSD and Chromium (i'm just picking projects i'm familiar with, no bias). So it might not have been 'many eyes', but the eyes of just one. edit: [0] a proper review step, what the openssl project does is have f…

The article says there was a reviewer who looked at this code before it was moved to the release branch.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#44

Post by mikeash » Thu, Apr 10, 2014, 3:14 PM UTC

dangayle wrote: post #36

notacoward wrote: post #29

Maybe the silver lining here is that it puts the final nail in the coffin for "many eyes make all bugs shallow" - which was always total BS from the day it was uttered. There's so much code out there, much of it highly specialized and even project-specific, that there are very few eyes looking at any particular piece of code, and not all eyes are connected to the greatest of brains. Most static code analyzers could h…

>> Maybe next time people will spend a little less time designing a logo and a little more time doing things that actually help (though that's a wish and what I expect is the exact opposite). So you want the graphic designers contributing to crypto code? As someone who is a mid level programmer but a decent/good designer, the only way I'm able to contribute to some projects is through things like logos. Don't use thi…

A lot of projects have no designers and the programmers spend a lot of time tweaking atrocious logos. I don't think that was meant to be a slight against designers. Probably the opposite, really: don't waste time screwing about with a logo if you don't have the talent, concentrate on the programming and either go without or find someone who can do it well.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#45

Post by fournm » Thu, Apr 10, 2014, 3:15 PM UTC

ajanuary wrote: post #38

fit2rule wrote: post #31

Earlier quoted context omitted.

I just ran Coverity on code that is similar to Heartbleed's bug, and it caught it. So, I think this is really just a glaring omission on a lot of peoples' part - but like you I also find it hard to believe nobody ran this code through static analysis. Its mind-boggling.

I don't know how Coverity works - is it possible that surrounding it with more complex code will cause it to miss the bug because it doesn't have enough information to not constantly raise false positives?

I'm not familiar with Coverity, but Sonar (for the Java world) is very similar in concept and will fail to detect things if there are enough issues before it in a file...

Which I would HOPE is not the case here.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#46

Post by flatline » Thu, Apr 10, 2014, 3:17 PM UTC

sillysaurus3 wrote: post #3

I believe it. Crafting a weapon that can be used by both you and your enemies would be pyrrhic. The lesson out of this ordeal is probably to be as skeptical as possible of everything you take for granted. How do you know that you're secure? What if your assumptions are wrong? Try to invent ways to break your own assumptions. The best way to protect yourself is to try to defeat yourself. Unfortunately, "ain't nobody g…

> Crafting a weapon that can be used by both you and your enemies would be pyrrhic.

In the long run, yes. In the short run, only you know about it and can exploit it from day 0, others are presumably going to take some time to find it, and it may go unnoticed for years or never be found (I understand the error was only present in some versions of OpenSSL and both older and more recent versions were free from it). I'm inclined to think the author made a simple mistake but this does not seem like sufficient incentive against someone introducing such a vulnerability.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#47

Post by tptacek » Thu, Apr 10, 2014, 3:18 PM UTC

JPKab wrote: post #42

I work with both private and public sectors in the DC area. One of the things that sucks about the Federal sector is that they are dominated by Microsoft and Oracle shills (the kind of IT pros who can't learn new skills unless its spoon fed pre-digested in the form of industry certification training) who do nothing but scream about the danger of open source. Now of course we all know that the only difference between…

So your theory is that nobody in the last couple years ever ran Coverity or Fortify on one of the top 5 security codebases on the whole Internet?

Re: 'Heartbleed' contributor denies he inserted it deliberately

#48

Post by nikcub » Thu, Apr 10, 2014, 3:18 PM UTC

sp332 wrote: post #43

nikcub wrote: post #33

Earlier quoted context omitted.

> Maybe the silver lining here is that it puts the final nail in the coffin for "many eyes make all bugs shallow" The OpenSSL project doesn't seem to have a 'review' step[0] in code commits, unlike FreeBSD, OpenBSD and Chromium (i'm just picking projects i'm familiar with, no bias). So it might not have been 'many eyes', but the eyes of just one. edit: [0] a proper review step, what the openssl project does is have f…

The article says there was a reviewer who looked at this code before it was moved to the release branch.

It refers to 'review' as in reviewing the features and how it is implemented. Here is the log:

http://rt.openssl.org/Ticket/Display.html?id=2658&user=guest...

That is very far from it being a security review, or any real proper review. It is more a request for comments (which defaults to code being committed)

You'll notice that the workflow for commits doesn't have a review stage, and it isn't implemented in the workflow software.

Compare to a chromium example, where each commit, eg.

http://src.chromium.org/viewvc/chrome?view=revision&revision...

has a review stage that the original committer doesn't have permissions for. In this case 3 reviewers for that commit:

https://codereview.chromium.org/231923002

Code doesn't get committed without at least 4 people, its like a 2-man rule that is enforced in the workflow.

In contrast the openssl process is that the same committer can push the code after getting no objections. There is a big difference in how each of these processes work.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#49

Post by Shish2k » Thu, Apr 10, 2014, 3:18 PM UTC

sillysaurus3 wrote: post #8

iwwr wrote: post #5

It may be impossible to distinguish genuine bugs from bug-backdoors, which is why it's important to start developing crypto in safer frameworks and languages. C considered harmful.

The problem is that GCs are considered harmful to crypto code, though that may be changing with Go. We won't know for about 5 years whether it's trustworthy, and even then, the side channel threat posed by GC may be worth worrying about. Some big-name cryptographers have started implementing some useful crypto services in Go, so we'll see whether it catches on. EDIT: Is the JVM generally trusted by cryptographers? I…

> The problem is that GCs are considered harmful to crypto code

Could a GC'ed language not just pause the GC thread while it executes a given block of code?

Re: 'Heartbleed' contributor denies he inserted it deliberately

#50

Post by danielweber » Thu, Apr 10, 2014, 3:20 PM UTC

talmand wrote: post #24

krstck wrote: post #13

It we start naming and shaming the coder for each flaw instead of working on fixing the process that allowed it to sneak through, we'll see a chilling effect on open source software. There's a reason we have tests and code reviews and security audits...

Unfortunately the tech industry seems to be in mob mode recently so I would think the chilling effect is already well underway. The fact that it has been suggested this was done intentionally before they know the whole story suggests this to me. Never mind the fact that the code was apparently reviewed, so I guess the reviewer would have been in on it as well. There are always people who prefer to play the blame game…

Part of me wants to see the team give the industry a big middle finger and quit the project, and now companies relying on it have to start spending money to keep it up instead of expecting it to be provided for free.

If something is important to you, you should spend more resources than zero on it.