On Fri, May 02, 2014 at 06:50:04PM -0600, Bob Beck wrote:
> What's their hangup with %n? We normally don't like polluting the world
> with #ifdef OPENSSL_NO_PERCENT_N... We normally nuke stuff like that
Well, it is an evil thing that is rarely used and well-known for some
format string vulnerabilities. So either adding this #define or
removing it from our libc wouldn't be a bad idea. But it is in POSIX,
right?
At a first look, I only found it in a few places of our tree where it
could be removed:
gcc, texinfo, curses, libform, sqlite, less, tmux, unbound, nsd
Not couting ports, but some software already seems to check if %n is
available to do a fallback otherwise.
Reyk
> On 2 May 2014 16:19, "enh" <[email protected]> wrote:
>
> > i maintain Android's C library which, as you may know, contains a lot
> > of OpenBSD code. i've been working to clean up our mess and get us
> > back in sync with upstream, and currently have 173 files that are
> > exactly the same as current upstream OpenBSD. (more than we have from
> > the other two BSDs put together.)
> >
> > the one thing i've had pushback on is that by switching to the current
> > upstream source i've effectively added support for printf(3)'s %n to
> > Android, which our security guys are not happy about. Android has
> > never supported %n before.
> >
> > ideally i'd like to have no differences between Android and OpenBSD in
> > the shared source files, because i've seen what a mess things were
> > when we diverged (and how many bugs went unfixed in Android despite
> > having been fixed for years upstream). so rather than start back on
> > the slippery slope of adding Android-specific hacks, i wondered if
> > you'd consider adding #ifndef REMOVE_PERCENT_N_SUPPORT (or whatever)
> > around the implementation of %n in lib/libc/stdio/vfprintf.c and
> > lib/libc/stdio/vfwprintf.c.
> >
> > you already have stuff like FLOATING_POINT and PRINTF_WIDE_CHAR so
> > there's some precedent here.
> >
> > thoughts? (assuming this is the right list. if not, please point me in
> > the right direction.)
> >
> > --elliott
> >
> >
