This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] vfprint: validate nargs and argument-based offsets
- From: Kees Cook <kees at outflux dot net>
- To: Tomas Hoger <thoger at redhat dot com>
- Cc: Andreas Jaeger <aj at suse dot com>, "Ryan S. Arnold" <ryan dot arnold at gmail dot com>, libc-alpha at sourceware dot org, Paul Eggert <eggert at cs dot ucla dot edu>, Roland McGrath <roland at hack dot frob dot com>, Andreas Schwab <schwab at linux-m68k dot org>
- Date: Mon, 5 Mar 2012 10:06:08 -0800
- Subject: Re: [PATCH] vfprint: validate nargs and argument-based offsets
- References: <20120302185346.GE3990@outflux.net><20120305180923.74a20a8f@redhat.com>
Hi Tomas,
On Mon, Mar 05, 2012 at 06:09:23PM +0100, Tomas Hoger wrote:
> On Fri, 2 Mar 2012 10:53:46 -0800 Kees Cook wrote:
>
> > The nargs value can overflow when doing allocations, allowing
> > arbitrary memory writes via format strings, bypassing _FORTIFY_SOURCE:
> > http://www.phrack.org/issues.html?issue=67&id=9
> >
> > This checks for nargs overflow and possibly allocates from heap
> > instead of stack, and adds a regression test for the situation.
>
> A commenter in Red Hat bugzilla proposed different fix:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=794766#c8
>
> The easiest fix would have been to restrict "nargs" to NL_ARGMAX.
>
> http://www.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html#tag_13_23_03_07
>
> which has the benefit of avoiding possibly large heap allocation in the
> bad case. Kees, have you considered such approach?
I have no problem with this. I opted against it originally since it seemed
like a needless limit to nargs when other options for handling it existed.
That said, it's a much simpler fix. :) Would anyone else prefer it over
the current fix?
-Kees
--
Kees Cook @outflux.net