Bug 26286 - *printf(3) etc should gain format string warnings
Summary: *printf(3) etc should gain format string warnings
Status: Open
Alias: None
Product: Documentation
Classification: Unclassified
Component: Manual Pages (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
Keywords: security
Depends on:
Reported: 2001-04-02 10:50 UTC by Mike Bristow
Modified: 2021-01-16 22:21 UTC (History)
4 users (show)

See Also:

file.diff (5.52 KB, patch)
2001-04-02 10:50 UTC, Mike Bristow
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Bristow 2001-04-02 10:50:00 UTC
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
Comment 1 dima 2001-04-03 02:38:26 UTC
Mike Bristow <mike@urgle.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
> diff -u -r1.11.2.4 err.3
> --- lib/libc/gen/err.3	2001/03/05 08:42:22
> +++ 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.
> +.Pp

[ 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").


					Dima Dorfman
Comment 2 Mike Bristow 2001-04-03 09:48:38 UTC
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
looks like.

Thanks for the feedback!

Mike Bristow, seebitwopie
Comment 3 dima 2001-04-04 02:15:57 UTC
Bengt Richter <bokr@accessone.com> 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.


					Dima Dorfman
Comment 4 nik freebsd_committer 2002-01-09 13:35:04 UTC
State Changed
From-To: open->suspended

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 
Comment 5 nik freebsd_committer 2002-01-09 13:36:50 UTC
State Changed
From-To: suspended->open
Comment 6 chris freebsd_committer 2002-06-14 00:43:23 UTC
Responsible Changed
From-To: freebsd-doc->chris

This is covered by my "SECURITY CONSIDERATIONS" man page work.
Comment 7 Mark Linimon freebsd_committer freebsd_triage 2004-08-26 03:25:44 UTC
Responsible Changed
From-To: chris->freebsd-doc

With bugmeister hat on, reassign from inactive committer.
Comment 8 Timothy Moore II 2017-09-01 15:36:00 UTC
Recommend closing this ticket after 10+ years of inactivity.
Comment 9 PauAmma freebsd_triage 2021-01-16 20:24:10 UTC
This has been gathering dust for nearly 20 years. Is it still relevant?