Subject: Re: proposal: disable *printf %n specifier in libc in NetBSD 1.5
To: None <tech-userlevel@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-userlevel
Date: 09/13/2000 01:04:31
[ On Monday, September 11, 2000 at 16:59:04 (-0400), Bill Sommerfeld wrote: ]
> Subject: Re: proposal: disable *printf %n specifier in libc in NetBSD 1.5 
>
> I'm attempting to reduce the magnitude of the harm which can result
> from a bug of this form, from a total system compromise, to a mere
> denial of service.

I would hope that a denial-of-service type of bug, especially in any
set-{user,group}-id program, would result in an advisory being issued --
there's nothing "mere" about them in my mind!!!  However if the
consensus is that an advisory is not necessary then yes it would be
sensible to do something about '%n' and leave the rest for later
audits.

If something is to be done explicitly about '%n' then I personally would
prefer some sort of run-time checking since that's the only way to
really be able to catch them.  Perhaps the discovery of a '%n' in the
format string could be made to cause a warning to be logged, and perhaps
if the program is running with enhanced privileges to simply ignore the
'%n' too.  As for controlling it (i.e. to allow a programmer in the know
to disable the checks), well that really needs to be done on a per-call
basis.  I don't know how best to do this, other than having a global
variable that the programmer must set before every call and which will
be reset within the printf() core.  This would allow lazy and diligent
programmers to put a wrapper macro in their config.h to cover all calls,
of course, but every compromise has its drawbacks.

Unfortunately this is like having a caching nameserver log that someone
else's nameserver is lame for some domain you're trying to access --
you're telling all the wrong people, but maybe if you make enough noise
someone will eventually tell the people who can actually do something to
fix the real problem.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>