Man pages for stdarg(3), err(3), setproctitle(3), syslog(3), printf(3),
gain a warning that missing arguments, or those of an unexpected type,
may cause random errors and/or a security risk.
Fix: This patch (should) apply to a -stable tree, I don't have a -current box
at the moment :(
$ man 3 printf
Mike Bristow <email@example.com> writes:
> >Number: 26286
> >Category: docs
> >Synopsis: *printf(3) etc should gain format string warnings
> Index: lib/libc/gen/err.3
> RCS file: /upstream-repositories/freebsd.org/src/lib/libc/gen/err.3,v
> retrieving revision 126.96.36.199
> diff -u -r188.8.131.52 err.3
> --- lib/libc/gen/err.3 2001/03/05 08:42:22 184.108.40.206
> +++ lib/libc/gen/err.3 2001/03/29 15:48:07
> @@ -97,9 +97,16 @@
> and a space are output.
> If the
> .Fa fmt
> -argument is not NULL, the
> -.Xr printf 3
> --like formatted error message is output.
> +argument is not NULL, then further output is controlled by treating
> +it as a format string that specifies how subsequent arguments (or
> +arguments accessed via the variable-length argument facilities of
> +.Xr stdarg 3 )
> +are converted for output, in the same way as
> +.Xr printf 3 .
> +If the format string specifies an argument that does not exist, or
> +a type different from that actually given, random errors, that
> +could cause a security risk, may occur.
[ Picking a random part of the patch to use as context. ]
The idea behind this is great, but I don't really like how the above
text is duplicated everywhere. It seems unnatural. Ideally, the
above would be replaced with a "see something(3) for information on
what [a format string] implies". Unfortunately, I don't know what
this something(3) should be; printf(3) is the first thing that comes
to mind, but printf(3) documents a particular function; it just so
happens that most C programmers' first sight of a format string was in
the context of a call to printf().
To demonstrate the importance of not duplicating this stuff, I point
out this [shortcoming]: the text above, which is pretty much the same
in all your other changes, doesn't mention the fact that using a
dynamic format string--more accurately, one which an outsider (user)
can control--can lead to disaster just as quickly as specifying the
wrong type of arguments. Although technically it's the same problem
(i.e., someone specifies a format the programmer didn't know about,
leading, e.g., err(3) to think argument x is of type y when it's
really of type z, or just nonexistent), it's a very common error (this
is what's recently became known as a "format string bug").
On Mon, Apr 02, 2001 at 06:38:26PM -0700, Dima Dorfman wrote:
> The idea behind this is great, but I don't really like how the above
> text is duplicated everywhere.
[ snip beginings of a vague idea ;-) ]
I see what you mean, and I agree to an extent (I'm not to sure if programmers
will follow the cross reference, though. Hmm. It's difficult to
get the balance between shoving info down peoples throat, and
repeating yourself so often it gets boring).
Perhaps style(9) is the right place to mention it in detail.
I'll try and work something up along those lines, and see what it
Thanks for the feedback!
Mike Bristow, seebitwopie
Bengt Richter <firstname.lastname@example.org> writes:
> (I am implicitly suggesting that security risk documentation
> be accumulated in a single place for reference and browsing.
> This would serve several goals at once, not least of which is
> a single instance of explanatory text to update when appropriate.
We already have this: http://www.FreeBSD.org/security/#spg
In a perfect world, most security bugs being found right now wouldn't
exist because all programmers would read that, and all the sites that
page links to, and know that passing the wrong data to the wrong
format specifier is a recipe for [security] disaster; unfortunately,
we don't live in a perfect world. Some programmers don't even bother
reading the man pages to look for security warnings, and many more
didn't read that page.
The best thing we can do is stick this information in their face.
Sticking outdated, wrong, or incomplete information in their face
doesn't make the problem better, however. That was my original
concern; if the information mentioned in each man page is incomplete
(and the patch submitted was), it may lead some to think that by
reading that they know enough, and not bother to investigate further.
That said, I'd like to make it clear that I'm not opposed to the patch
in general. I'm just concerned that keeping it up to date will be a
pretty big problem, and thus it may end up doing more harm than good.
Discussion hasn't thrown up any concrete plans as to the best way to handle
this, and no implementations have been forthcoming. Hopefully this will spur
someone on to do the necessary work, but if not, I'll close this in two
This is covered by my "SECURITY CONSIDERATIONS" man page work.
With bugmeister hat on, reassign from inactive committer.
Recommend closing this ticket after 10+ years of inactivity.