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.
manoj
--
"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: