[PATCH] cgit: use strtol_i instead of atoi

[PATCH] cgit: use strtol_i instead of atoi

[ncopa]

The use of atoi triggers a false positive in nessus security scanner who
believes it is an SQL injection.

Make nessus users happy by making the integer conversion slightly more
strict.

Signed-off-by: Natanael Copa <ncopa at alpinelinux.org>
---
 cgit.c | 18 +++++++++++-------
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/cgit.c b/cgit.c
index ae413c6..fccde9e 100644
--- a/cgit.c
+++ b/cgit.c
@@ -307,7 +307,7 @@ static void querystring_cb(const char *name, const char *value)
 		ctx.qry.sha2 = xstrdup(value);
 		ctx.qry.has_sha1 = 1;
 	} else if (!strcmp(name, "ofs")) {
-		ctx.qry.ofs = atoi(value);
+		strtol_i(value, 10, &ctx.qry.ofs);
 	} else if (!strcmp(name, "path")) {
 		ctx.qry.path = trim_end(value, '/');
 	} else if (!strcmp(name, "name")) {
@@ -317,22 +317,26 @@ static void querystring_cb(const char *name, const char *value)
 	} else if (!strcmp(name, "s")) {
 		ctx.qry.sort = xstrdup(value);
 	} else if (!strcmp(name, "showmsg")) {
-		ctx.qry.showmsg = atoi(value);
+		strtol_i(value, 10, &ctx.qry.showmsg);
 	} else if (!strcmp(name, "period")) {
 		ctx.qry.period = xstrdup(value);
 	} else if (!strcmp(name, "dt")) {
-		ctx.qry.difftype = atoi(value);
+		int difftype = 0;
+		strtol_i(value, 10, &difftype);
+		ctx.qry.difftype = difftype;
 		ctx.qry.has_difftype = 1;
 	} else if (!strcmp(name, "ss")) {
 		/* No longer generated, but there may be links out there. */
-		ctx.qry.difftype = atoi(value) ? DIFF_SSDIFF : DIFF_UNIFIED;
+		int n = 0;
+		strtol_i(value, 10, &n);
+		ctx.qry.difftype = n ? DIFF_SSDIFF : DIFF_UNIFIED;
 		ctx.qry.has_difftype = 1;
 	} else if (!strcmp(name, "all")) {
-		ctx.qry.show_all = atoi(value);
+		strtol_i(value, 10, &ctx.qry.show_all);
 	} else if (!strcmp(name, "context")) {
-		ctx.qry.context = atoi(value);
+		strtol_i(value, 10, &ctx.qry.context);
 	} else if (!strcmp(name, "ignorews")) {
-		ctx.qry.ignorews = atoi(value);
+		strtol_i(value, 10, &ctx.qry.ignorews);
 	}
 }
 
-- 
2.4.0

[PATCH] cgit: use strtol_i instead of atoi

[Jason]

Anybody have any objections to this? In some cases it's slightly more
verbose, but otherwise, I can't see any downsides.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/cgit/attachments/20150513/803ea6a8/attachment.html>

[PATCH] cgit: use strtol_i instead of atoi

[john]

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.

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.

[PATCH] cgit: use strtol_i instead of atoi

[john]

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.
> 
> 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?  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.

[PATCH] cgit: use strtol_i instead of atoi

[jamie.couture]

On Wed, May 13, 2015 at 02:45:56PM +0100, John Keeping 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.
> > 
> > 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?  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.

Exactly.

I'm not familiar with the utility, but can nessus have exceptions to
a rule?   In cgit's case, I don't see the use of atoi() as a problem
in this context.

[PATCH] cgit: use strtol_i instead of atoi

[ncopa]

On Wed, 13 May 2015 10:57:00 -0400
Jamie Couture <jamie.couture at gmail.com> wrote:

> On Wed, May 13, 2015 at 02:45:56PM +0100, John Keeping 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.
> > > 
> > > 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?  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.
> 
> Exactly.
> 
> I'm not familiar with the utility, but can nessus have exceptions to
> a rule?

I am not familiar with the utility either and I have no control over
it. I just get a report once in a while with graphs and colors and a
comment "There are some RED sql injections here and your server has the
worst security score".

I did send them an analyze once with a suggestion how to fix nessus
(prefixing the string with a space would have fixed the false positive
while will trigger on real sql injection vulnerabilities), however the
people who generates those reports probably did not understand any of
what i said, nor did they care. They only want their colored graphs to
be green.

(so I have currently added an iptables rule to drop tcp 80 from the
scanning ip addr)

> In cgit's case, I don't see the use of atoi() as a problem in this
> context.

You are absolutely right. atoi in cgit is no problem. But IMHO,
ignoring "1 and 1=0" instead of reading it as 1 is more technically
correct and thus improves quality of cgit slightly.

Should I send a new patch with better commit message?

-nc

[PATCH] cgit: use strtol_i instead of atoi

[ncopa]

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