My priors on this being deliberate are pretty low, but I'd expect this denial either way so it really isn't evidence against the idea.
'Heartbleed' contributor denies he inserted it deliberately
21–30 of 86 posts
Re: 'Heartbleed' contributor denies he inserted it deliberately
#22I 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.
Re: 'Heartbleed' contributor denies he inserted it deliberately
#23I 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'd be amazed if he doesn't break from the pressure and/or abuse.
Re: 'Heartbleed' contributor denies he inserted it deliberately
#24It 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 instead of actually working to solve the problem.
Re: 'Heartbleed' contributor denies he inserted it deliberately
#25I 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.
Re: 'Heartbleed' contributor denies he inserted it deliberately
#26Earlier quoted context omitted.
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.
Objective-C programmers have been using refcounting at scale for at least 2 decades.
No problems here.
Re: 'Heartbleed' contributor denies he inserted it deliberately
#27I 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..
Let the programmer who has never written a bug cast the first stone.
Re: 'Heartbleed' contributor denies he inserted it deliberately
#28Earlier 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…
"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.
I don't know enough about it to say anything more than "I noticed some big-name cryptographers have begun writing crypto services in Go, so maybe it's safe." Trusting expert cryptographers to make safe decisions and then waiting five years for cryptanalysis to catch up is probably a safe course of action. (Moreso the "wait five years for cryptographers to poke holes in it" part.)
I remember some discussion on HN where someone mentioned that GCs pose a problem for secure code due to the non-deterministic nature of GC. There's apparently a nonzero chance of introducing a side-channel attack via GC. Until we're certain that chance is far closer to "zero" than "non-zero," we should either study that threat vector in detail or find a safer option.
It would be horrible to switch to something which is then proven to be broken in some fundamental and unfixable way, such as a GC side channel attack.
Re: 'Heartbleed' contributor denies he inserted it deliberately
#29Maybe 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 have caught this particular bug, as it requires only a fairly simple kind of reasoning about allocated vs. used length. In fact I believe it probably was found by static analysis before being reported by a human, which is a shame because it misses an opportunity to highlight the value of such tools. 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).
The real lesson here is that we should apply as many different tools and processes as we can at improving code quality for critical infrastructure. Code reviews are nice. Static analysis is nice. Detailed tests are nice. However, none of these alone is sufficient even when pursued with fanatical devotion.
Re: 'Heartbleed' contributor denies he inserted it deliberately
#30Earlier quoted context omitted.
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.
Objective-C programmers have been using refcounting at scale for at least 2 decades. No problems here.
How is it possible to use refcounting for GC while also correctly handling cyclic references?
EDIT: Objective-C doesn't solve the problem at all. (More precisely, it requires manual intervention by the programmer.) See http://stackoverflow.com/questions/6260256/what-kind-of-leak...
From the article: "This occurs when one object has a strong pointer to another, but the target object has a strong pointer back to the original."
Some backrground info on Objective-C's memory management: http://stackoverflow.com/questions/7874342/what-is-the-diffe...
It's an interesting approach to insert release calls at compile time. Maybe it's worth not solving the cyclic reference problem in exchange for determinism. Thank you for pointing that out.