Re: conntrack-tools: fscanf() call usage

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

 



From: Thomas Jarosch <thomas.jarosch@xxxxxxxxxxxxx>
Sent: Thu 25 Aug 2011 22:22:58 EST

> Hi there,
>
> the conntrack-tools have an fscanf() call without a
> field width limit. There's a small issue with this:
>
> [conntrack-tools/src/conntrack.c:1875]: (warning) scanf
> without field width limits can crash with huge input data
>
> Simple PoC can be found here:
> http://marc.info/?l=gimp-developer&m=129567990905823&w=2

This looks like a bug in scanf, I suggest fixing it there. I don't know
why the cppcheck authors decided that all the users needed fixing.

> The code currently looks like this:
>     "if (fscanf(fd, "%d", &count) != 1) {"
>
>
> A limit to uint32 number of digits should be sane, also on 64bit machines.
> That should still give us enough conntrack entries - even for Jesper.
>
> I goofed around with scanf() some more and discovered that basically any
> field limit should do (even 2000+). Otherwise scanf() seems to use a fixed
> default buffer if the size is not known in advance.

The size limit is 0x200000. It's not clear to me yet what exactly is
causing this.

> Proposed change looks like this:
>     "if (fscanf(fd, "%10d", &count) != 1) {"
>
> Is that a sane thing to do or unnecessary?

Working around the problem in every program that uses scanf is not the
right thing to do.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Netfitler Users]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux