[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Developers vs Uploaders

On Wed, 21 Mar 2007 12:28:22 -0700, Don Armstrong <don@debian.org> said: 

> On Wed, 21 Mar 2007, Manoj Srivastava wrote:
>> The implication, unless I am misreading things here, is that code
>> reviews and inspection of upstream changes are ineffectual. Given
>> that reviewing code for security is a labour intensive process, the
>> inference is that it is not worth doing proactive inspections of
>> code for potential problems, and it is better to work on other
>> aspects of the project.
>> I find that a startling conclusion, and I am wondering if I
>> misunderstood, or should we really open the floodgates to
>> uninspected code, on the grounds that inspections buy us little, if
>> anything?

> The point that is (or, rather appears to be) being made is that the
> floodgates are already open. Unless you have a relatively complete
> and continuously updated understanding of the security bugs which
> affect the language in which the package is written and the
> operating system upon which it is running, it is almost impossible
> to do a meaningful code review for security.[1]

        I beg to differ.  Buffer overflows are _still_ being
 exploited, decades after it is known that unchecked user input fed to
 memory allocated on the stack.  And it does not take a rocket
 scientist to spot a buffer overflow.

        Opening file descriptors in /tmp without adequate checking is
 also something that can be spotted easily.

        I think that evil hacker dudes are not quite so devilishly
 clever; there are broad swathes of exploits that stem from very few,
 well known classes of programming errors.  If the code paths that
 devolve from user inputs are checked for proper sanitization, and
 information flow nodes (depicted by the open file descriptors) are
 also looked at, you can indeed avoid lots of issues that can come
 back to bite one.  And you do not need to be up to snuff in the
 latest kiddie exploit to do so.

> I don't think that's a strong argument against doing them because
> you can still catch bugs (security and otherwise) that way, but it
> is a strong argument that code reviews by the maintainer are not
> enough.

        Nothing is ever enough.  There is no last bug, security or
 otherwise.  But perfection is not the enemy of the good -- and
 stopping efforts to improve security or decrease the bug density
 because one can not reach perfection is .... weak.

> It also raises the question that the time spent doing security
> reviews of code in Debian by maintainers of their own packages may
> be better spent looking for known classes of vulnerabilities
> distribution wide.

        I am missing the logic here. Are you implying all 1038 of us
 spend time doing system wide  searches for known classes of
 vulnerabilities?  I doubt that very many of us have the resources, or
 any specialized knowledge of the pattern of code (since a system-wide
 search is unlikely to be done by mere browsing) to conduct a wide
 hunt of specific vulnerabilities.

        I suspect that general user input sanitization, buffer
 overflow checks, and basic information flow analysis that can be done
 by most of the rest of us who do not have special mad security hacker
 skillz are a complimentary activity to the cross application
 vulnerability mining; and stopping either one because neither is
 "perfect" does not seem to be advisable.

"I prefer to think that God is not dead, just drunk" John Huston
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Reply to: