Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

'Heartbleed' contributor denies he inserted it deliberately

smh.com.au

Post reply on HN
Print view View original

31–40 of 86 posts

Re: 'Heartbleed' contributor denies he inserted it deliberately

#31

Post by fit2rule »

peeters wrote: post #25
fit2rule wrote: post #22

I just can't understand why such critical components as OpenSSL just don't use Code Coverage tools like Coverity to find such things as this? Testing, coverage certification, static analysis: this would have been caught if these tools were being used.

It would shock me if those tools would actually have caught this bug. That would imply that no benevolent contributor or researcher had run them against OpenSSL in the last two years, which I find incredibly hard to believe, as static analysis is a logical first step in researching a code for vulnerabilities, and OpenSSL is probably in the top 5 most valuable pieces of software to validate.

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.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#32

Post by protomyth »

weavie wrote: post #9

I can't imagine what this guy must be feeling right now. I find it embarrassing enough when I am outed in my small team for producing a bug that makes it into production. To be known around the entire internet to have caused the largest security bug in recent times must be quite a slammer. I really hope it doesn't affect his career..

I'm actually more worried that this will result in a civil lawsuit from one of the affected companies. In an ideal world[1], it would get thrown out immediately, but I'm a bit worried. That would have a heck of a chilling affect.

1) and a simple reading of the license

Re: 'Heartbleed' contributor denies he inserted it deliberately

#33

Post by nikcub »

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 feedback on commits (which is what the OP article is referring to). see below.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#34

Post by _ak »

weavie wrote: post #9

I can't imagine what this guy must be feeling right now. I find it embarrassing enough when I am outed in my small team for producing a bug that makes it into production. To be known around the entire internet to have caused the largest security bug in recent times must be quite a slammer. I really hope it doesn't affect his career..

He works for T-Systems, which belongs to Deutsche Telekom. His job is pretty safe, I would say. People working for Deutsche Telekom work under conditions similar to German civil servants in terms of terminability.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#35

Post by ajanuary »

peeters wrote: post #25
fit2rule wrote: post #22

I just can't understand why such critical components as OpenSSL just don't use Code Coverage tools like Coverity to find such things as this? Testing, coverage certification, static analysis: this would have been caught if these tools were being used.

It would shock me if those tools would actually have caught this bug. That would imply that no benevolent contributor or researcher had run them against OpenSSL in the last two years, which I find incredibly hard to believe, as static analysis is a logical first step in researching a code for vulnerabilities, and OpenSSL is probably in the top 5 most valuable pieces of software to validate.

Someone commented (I can't find it now) that post disclosure they ran 5 or 6 coverage tools and one of them flagged it.

They didn't say how much else got flagged, and how many false positives there were. It's very easy to retrospectively look through the list and say "oh yeah, there it is, amongst this big pile of nonsense".

Re: 'Heartbleed' contributor denies he inserted it deliberately

#36

Post by dangayle »

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 this straw man argument to make your point, which is otherwise valid.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#37

Post by raesene3 »

Hopefully one positive thing that will come out of this whole Heartbleed thing is that companies making extensive use of Open Source software for security critical purposes will consider contributing to ensure that security reviews are carried out on them.

The cost of regularly reviewing codebases like OpenSSL would likely not be that high when compared to the potential impact of a breach because of a flaw in the software.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#38

Post by ajanuary »

fit2rule wrote: post #31
peeters wrote: post #25

Earlier quoted context omitted.

It would shock me if those tools would actually have caught this bug. That would imply that no benevolent contributor or researcher had run them against OpenSSL in the last two years, which I find incredibly hard to believe, as static analysis is a logical first step in researching a code for vulnerabilities, and OpenSSL is probably in the top 5 most valuable pieces of software to validate.

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?

Re: 'Heartbleed' contributor denies he inserted it deliberately

#39

Post by [deleted] »

tptacek wrote: post #19

Strangely, nobody's tracking down the nginx developer who inserted the exact same bug into nginx just a few years back (a NUL in a header would cause the header copies, done using strncpy, to abort early and expose uninitialized memory). He must have been an NSA plant too, right?

[deleted]

Re: 'Heartbleed' contributor denies he inserted it deliberately

#40

Post by tptacek »

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…

It sure would be nice if some of those designers would take a whack at the Mozilla certificate configuration UI. It hasn't meaningfully changed in a decade, it's one of the Internet's biggest security flaws, and it's something any UX person could safely propose changes to.
Post reply on HN