De Raadt Doubts Alleged Backdoors Made It Into OpenBSD 136
itwbennett writes "In follow-up to last week's controversy over allegations that the FBI installed a number of back doors into the encryption software used by the OpenBSD operating system, OpenBSD lead developer Theo de Raadt said on a discussion list Tuesday, that he believes that a government contracting firm that contributed code to his project 'was probably contracted to write backdoors,' which would grant secret access to encrypted communications. But that he doesn't think that any of this software made it into the OpenBSD code base."
Re:Strange how much fuss... (Score:4, Interesting)
...can be made over something so obvious. OpenBSD's code has been screened again and again. If something was amiss somebody would have noticed it . . .
Yeah just look for the parts commented //super secret FBI backdoor, shhh!
You obviously have not seen things like this http://underhanded.xcott.com/ [xcott.com]
Re:Audit necessary (Score:5, Interesting)
Well, great way to halt the actual development, right?
Remember how Microsoft accused ReactOS of copying NT code?
They spent LOTS of time auditing.
The code doesn't even have to be in the source (Score:3, Interesting)
If they can get a backdoor built into the compiler used to build the binaries for the general releases, the backdoor doesn't have to be anywhere in the source.
So, yeah, an audit isn't foolproof.
Re:Audit necessary (Score:4, Interesting)
The goal of the contest is to write a chunk of code that does something, well, underhanded that is difficult to detect even upon close examination of the code.
First two examples on the front page haven't passed even through my shallow code review.
The third sample failed at readability (ambiguous operator precedence) and I would have immediately subjected it to re-factoring.
It is not that difficult to detect the problems.
My first, the most generic rule of code review: code works much like the way it looks. And I know for a fact that OpenBSD folks use that rule too.
P.S. The 3 samples I looked at are the winners from the year 2008.
Re:Audit necessary (Score:2, Interesting)
To me, it doesn't matter where in the implementation the bug is, since it has to be rewritten anyway for readability reasons.
It also BTW would trigger another alarm in the eyes of seasoned code reviewers: in the "isdigit() == true" branch it looses the read character, printing '0' instead.
Not convinced .. (Score:3, Interesting)
Paranoid mickey's take on it .. Interesting read.
http://mickey.lucifier.net/b4ckd00r.html [lucifier.net]
Re:Audit necessary (Score:4, Interesting)
All of these would be sore thumbs in a code review. Getting this into production code would have to rely on your co-contributors being nitwits.
Working at a Very Highly Notable Computer Operating System Producing Company, I was hit by a number of reviews that likely would not have caught any of this code, because no one I worked with cared particularly hard about code-reviews at all. I would constantly get code reviews back that state: "looks good", and then after performing my own code review, I would pull up some crazy stupid easy-to-catch bug that anyone should have seen if they actually looked over my code review.
And when I gave these code reviews to others, what I received back were people being pissed and upset that I would nitpick their code.
As for using totally stupid and inefficient algorithms, I hit across a number of those while working on a bug, and I attempted to refactor them when I could. One of the most egregious issues I dealt with was a config file reader that listed magic constants THREE TIMES throughout the code. Once for a a validity check, the next for a more robust check, and then a huge IF-THEN-ELSE block to define behavior. After refactoring this to use ONE set of definitions for these magic constants, the code was so altered that it could not be backported at all.
I absolutely don't trust code reviews from anyone outside of the open source community anymore. They have their own job to do, and they rarely consider code reviews of someone else's code to be their "job". They view it as being non-productive and non-work... like going to meetings. Volunteers at least take the code-reviews seriously, as it is their own time that they're spending on it.