login
Header Space

 
 

Quote: Responding Correctly

May 16, 2008 - 7:32pm
Submitted by Jeremy on May 16, 2008 - 7:32pm.

"I think people are placing too much blame on valgrind. valgrind doesn't tell you 'Delete this line of code.' It says 'You are using uninitialized memory here.' The correct fix is to initialize the memory, not delete the line of code. It's not about trusting or not trusting the tool; it's about responding correctly."

— Ted Unangst, in a May 16th, 2008 message on the OpenBSD -misc mailing list.

The real problem is the

May 21, 2008 - 2:24pm
Anonymous (not verified)

The real problem is the person serving as Debian maintainer of the openssl package. Only a bloody amateur would think that removing a function call would not change the meaning of a program. What will he do next? Put an #if 0 / #endif bracket around the contents of the main() function, so that there will no longer be valgrind hits?

It continues to boggle my mind that this person is permitted to continue in that role.

It was known for a fact that

May 22, 2008 - 7:17pm

It was known for a fact that OpenSSL was deliberately using uninitialized stack data as one of its entropy sources. If you want to remove uninitialized stack data from the entropy pool, you delete a function call -- because feeding a bunch of zeroes into the entropy pool doesn't make sense.

Furthermore, even if he had zeroed out the buffer at the same place, he would still have introduced the same bug. I believe mr. Ted Unangst is trolling without a clue here.

The actual problem is that given maintainer didn't look far enough to notice that the buffer was passed in as a function argument, and the uninitialized pointer came from elsewhere.

Re: It was known for a fact that

May 28, 2008 - 2:04am
Anonymous (not verified)

The actual problem is that given maintainer didn't look far enough to notice that the buffer was passed in as a function argument, and the uninitialized pointer came from elsewhere.

So, what you are really saying is that the Debian maintainer was a bloody moron who decided to poke around the code of the central security library without bothering to look further than his nose to check ramifications of the code he was modifying, or atleast having the good sense to ask someone who knew the code better.

When you are not 100% sure what some code in a sensitive library does, you leave it the fuck alone!

I fully agree with the original commenter above, allowing this person to continue maintaining such a crucial piece of infrastructure is inexusable.

Why are you even responding

June 3, 2008 - 11:23pm

Why are you even responding to me? You completely missed the point of what I was saying. I am not defending the Debian developer's decision, I am addressing Ted Unangst's idea of "responding correctly". His suggestion of seeding the random number generator with a zeroed-out buffer would not have had a better result.

What's worse, he knows that there was a security problem in the given piece of code, yet is still proposing an equally broken solution AFTER the fact? The only conclusion I can draw is that he is more clueless than the Debian developer who wrote the original patch.

You are correct

June 16, 2008 - 1:45am
The Anonymous from above (not verified)

You are correct, I misread your post as defending the Debian developer. We are in agreement that what the Debian developer did was boneheaded. I also agree that OpenBSD developer's proposal taken at face value is equally boneheaded, but he may have been speaking in generalities (which is no excuse if he actually acts based on those generalities).

In either case, the point stands: when you don't fully understand some sensitive code, the "correct response" is to not mess with it!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
speck-geostationary