Subject: Re: proposal: disable *printf %n specifier in libc in NetBSD 1.5
To: None <sommerfeld@orchard.arlington.ma.us>
From: Chris G. Demetriou <cgd@sibyte.com>
List: tech-userlevel
Date: 09/11/2000 13:06:54
sommerfeld@orchard.arlington.ma.us (Bill Sommerfeld) writes:
> Fixing and issuing advisories for format string bugs may end up
> consuming a significant fraction of the security officer's bandwidth.
>
> I'd like someone who's advocating keeping %n enabled by default to
> step forward and volunteer to handle fixing and issuing advisories for
> all current and future format-string security problems discovered in
> NetBSD and NetBSD packages.

(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), and now you want somebody else to take
responsibility for the problem you've been trying to solve (badly),
them (i.e., the problem you've been trying to ignore), _and_ a whole
lot of additional unspecified problems which may well be unrelated
(e.g. simple incorrect use of sprintf())?

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


(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.

The responsibility for these things shouldn't be on some random person
(it seems you'd like to say me 8-), but the people who import and/or
change the code.  After all, they're the ones proposing to make the
system be insecure or its programs more crash-prone, or ...





cgd