Subject: Re: proposal: disable *printf %n specifier in libc in NetBSD 1.5
To: Chris G. Demetriou <cgd@sibyte.com>
From: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
List: tech-userlevel
Date: 09/11/2000 16:23:48
> (1) funny, you've been trying to ignore a whole class of format-string
> security problems (the denial of service caused by other malicious
> abuses of unchecked data, and who knows what the actual end result of
> those could be if a critical security-related service goes down
> because of them)

I'm attempting to reduce the amount of damage which can be done by an
erroneous program of this form.  To say that all the erroneous
programs should be fixed is "nice", and I don't have any objection to
this, but the fundamental reality is that there's a lot of buggy code
out there, and knocking an entire class of bugs from "let attacker
execute arbitrary code" to a mere "simple denial of service" is, IMHO,
a worthwhile change.

I'm certainly not going to stop anyone from fixing problems of this
form, but I *am* attempting to reduce the security impact of a large
class of bugs.

> That sounds like bullying in order to try to get your (i'll say it
> again: technically unsound) way.

The amount of time I have for NetBSD is limited.  I can spend that
time issuing advisories for format bugs in packages, or I can spend a
fraction of that time preventing the entire class of bugs and have
more time left over to work on interesting features like SMP.

> (2) This actually brings up a larger, more serious point:
> 
> Before packages which set up network server ports or are set-id or may
> have other security implications are created, they should be audited,
> and the responsibility for doing that should be on the people who want
> to create them.  Even ignoring the %n problems, who's to say that they
> have been converted to avoid actual buffer overruns, e.g. by using
> snprintf() rather than sprintf()?
> 
> The same goes for programs in our main source tree, actually.

Dream on.  Even if we did impose this level of auditing on the system,
there would still be bugs which got through the auditing pass...  And
when broken code gets discovered after the fact, it becomes the
responsibility of the security officer to fix it.

					- Bill