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

Re: 'Heartbleed' contributor denies he inserted it deliberately

#11

Post by Karunamon » Thu, Apr 10, 2014, 2:11 PM UTC

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

The armchair crypto brigade aren't helping much, either, by passing around these completely unfounded accusations of malfeasance.

I'm all for being aware of the possibility that shenanigans are involved, but until proof comes out, it is nothing but a possibility, and a remote one at that.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#12

Post by systematical » Thu, Apr 10, 2014, 2:11 PM UTC

iwwr wrote: post #6

venomsnake wrote: post #4

Earlier quoted context omitted.

Just wait till you have been told - it is running too fast so the client won't perceive it as a "serious" software ... slow it down.

The problem is not that bugs happen, but that certain categories of bugs still happen when we have means to avoid them altogether.

We lack perfection and we are not always programming at peak form even when are programming at near peak (personal) efficiency we are still not perfect. This bug even made it through a code review.

Makes me wonder how many serious bugs I have pushed to production in the last year or two. Yikes.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#13

Post by krstck » Thu, Apr 10, 2014, 2:12 PM UTC

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

Re: 'Heartbleed' contributor denies he inserted it deliberately

#14

Post by gsnedders » Thu, Apr 10, 2014, 2:20 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…

Rust provides memory safety without a GC, which seems more promising than anything else for this sort of application.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#15

Post by pornel » Thu, Apr 10, 2014, 2:23 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…

C vs GC is a false dichotomy.

There can be safer-than-C languages that don't use GC, e.g. you don't need GC for array bounds checking. You can use reference counting for more deterministic garbage collection.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#16

Post by chiph » Thu, Apr 10, 2014, 2:27 PM UTC

Any C programmers who have never failed to check their bounds? Anyone? Anyone? Because everyone has done it.

Now would be a nice time for one of the Lint vendors to donate copies of their product to some of the OpenSSL team members, and for them to dedicate some resources into fixing the more important stuff it finds.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#17

Post by sillysaurus3 » Thu, Apr 10, 2014, 2:28 PM UTC

pornel wrote: post #15

sillysaurus3 wrote: post #8

Earlier quoted context omitted.

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…

C vs GC is a false dichotomy. There can be safer-than-C languages that don't use GC, e.g. you don't need GC for array bounds checking. You can use reference counting for more deterministic garbage collection.

Refcounting unfortunately fails for GC because it can't handle cyclic dependencies, e.g. object A references object B which references object A, now neither object will ever be freed even if nothing else references A or B.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#18

Post by jerf » Thu, Apr 10, 2014, 2:29 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, though that may be changing with Go."

I'm curious what about Go's GC leads you to say that? Is it that when you get a new chunk of bytes, they've been pre-zeroed? That's not specifically a characteristic of the GC but it's my best guess. Otherwise I don't know what it would be, which is why I ask.

Re: 'Heartbleed' contributor denies he inserted it deliberately

#19

Post by tptacek » Thu, Apr 10, 2014, 2:32 PM UTC

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?

Re: 'Heartbleed' contributor denies he inserted it deliberately

#20

Post by kmkemp » Thu, Apr 10, 2014, 2:32 PM UTC

Karunamon wrote: post #11

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

The armchair crypto brigade aren't helping much, either, by passing around these completely unfounded accusations of malfeasance. I'm all for being aware of the possibility that shenanigans are involved, but until proof comes out, it is nothing but a possibility, and a remote one at that.

"Never attribute to malice that which is adequately explained by stupidity." Obviously "stupidity" is way too strong here, but the principle still applies.