Re: Buffer overflows

["Reece Dunn" <msclrhd@googlemail.com>]

On 30/08/2007, Timo Sirainen <tss@iki.fi> wrote:
> On 30.8.2007, at 23.46, Linus Torvalds wrote:
>
> > On Thu, 30 Aug 2007, Timo Sirainen wrote:
> >>
> >> Looks like nothing has happened since my last mail about this
> >> (http://marc.info/?l=git&m=117962988804430&w=2).
>
> > If you were to send in a patch that simply just fixed some random case
> > without introducing the other stuff in forms that nobody is used to,
> > people would probably react more.
>
> The problem is that the git code is full of these random cases. It's
> simply a huge job to even try to verify the correctness of it. Even
> if someone did that and fixed all the problems, tomorrow there would
> be new ones because noone bothers to even try to avoid them. So there
> really isn't any point in trying to make git secure until the coding
> style changes.

You don't want a manual check to do these kinds of checks. Not only is
it a huge job, you have the human factor: people make mistakes. This
is (in part) what the review process is for, but understanding how to
identify code that is safe from buffer overruns, integer overflows and
the like is a complex task. Also, it may work on 32-bit which has been
verified, but not on 64-bit.

It would be far better to specify the rules on how to detect these
issues into a static analysis tool and have that do the checking for
you. Therefore, it is possible to detect when new problems have been
added into the codebase. Does sparse support identifying these issues?

> The code should be easy to verify to be secure, and with some kind of
> a safe string API it's a lot easier than trying to figure out corner
> cases where strcpy() calls break.

Why is it easier? If you have a fixed-size buffer, why not use
strncpy, which is what a safe string API is essentially doing anyway?

In this case, detecting strcpy usage can be done via grep. This is
quick, simple and easy to repeat. Other things are more complicated,
which is where automated verification tools help.

- Reece