[PATCH] cgit: use strtol_i instead of atoi

[Natanael Copa]

On Wed, 13 May 2015 14:45:56 +0100
John Keeping <john at keeping.me.uk> wrote:

> On Wed, May 13, 2015 at 02:41:24PM +0100, John Keeping wrote:
> > On Wed, May 13, 2015 at 03:35:29PM +0200, Jason A. Donenfeld wrote:
> > > Anybody have any objections to this? In some cases it's slightly more
> > > verbose, but otherwise, I can't see any downsides.
> > 
> > It's worse if there is trailing data.  Since there's nothing obvious we
> > can do if the input is bad, I'm not sure how much we care (i.e. ignoring
> > the return value from strtol_i is OK) but whereas atoi will parse a
> > valid value followed by trailing garbage strtol_i will just fail.

This is the point of the patch. If the whole string is not a numeric
value (if there are any trailing garbage at the end) then ignore it.

> > Worse than that, if it fails it leaves the result uninitialized, which
> > doesn't matter in the cases where we just update a variable, but at
> > least one part of this patch introduces a new variable that is not set
> > if strtol_i fails.
> 
> Oops... I didn't double-check the patch before sending, it does always
> initialize the variables first so the only worry is trailing garbage.
> 
> Of course, if atoi leads to SQL injection, what makes strtol safe? 

There is no SQL injection. There is no SQL in cgit. The nessus scanner
is just being stupid.

This is from the report:

+ The 'showmsg' parameter of the /cgit/ncopa/luarc/log/ CGI :

/cgit/ncopa/luarc/log/?h=master&qt=grep&q=&showmsg=1+and+1=0

-------- output --------
<td class='logo' rowspan='2'><a href='/cgit/'><img src='http://wik [...]
<td class='main'><a href='/cgit/'>index</a> : <a title='luarc' hre [...]
<input type='hidden' name='showmsg' value='1'/><input type='hidden' name
='qt' value='grep'/><input type='hidden' name='q' value=''/><select name
='h' onchange='this.form.submit();'>
<option value='master' selected='selected'>master</option>
</select> <input type='submit' name='' value='switch'/></form></td></tr>
-------- vs --------
<td class='logo' rowspan='2'><a href='/cgit/'><img src='http://wik [...]
<td class='main'><a href='/cgit/'>index</a> : <a title='luarc' hre [...]
<input type='hidden' name='qt' value='grep'/><input type='hidden' name='
q' value=''/><select name='h' onchange='this.form.submit();'>
<option value='master' selected='selected'>master</option>
</select> <input type='submit' name='' value='switch'/></form></td></tr>
------------------------


As you see, nessus passes showmsg="1 and 1=0" and in the output it find
that showmsg is set to '1' (due to the use of atoi() to parse it) and
concludes that the string '1 and 1=0' was executed as SQL. Of course
there was no SQL executed whatsoever.

On the other hand "1 and 1=0" is not a valid number either so it is
technically correct to ignore it.

> The
> test seems fundamentally useless; AFAICT the whole point is that if I
> parse some user input and use without validating it then I can end up
> doing something like:
> 
> 	int num_items = <user input>;
> 	items = malloc(num_items * sizeof(*items));
> 
> leading to integer overflow.  But the mechanism used to convert the user
> input from a string to an integer is completely irrelevant.

Yes. This is just a minor improvement that makes cgit ignore strings
that technically are not numbers, only because it is a good habit to be
strict. It has nothing to do with real SQL injections.

-nc