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 :( How-To-Repeat: $ man 3 printf
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 1.11.2.4 > diff -u -r1.11.2.4 err.3 > --- lib/libc/gen/err.3 2001/03/05 08:42:22 1.11.2.4 > +++ 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"). Regards, Dima Dorfman dima@unixfreak.org
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. Hmm. I'll try and work something up along those lines, and see what it looks like. Thanks for the feedback! -- Mike Bristow, seebitwopie
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. Regards, Dima Dorfman dima@unixfreak.org
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 months.
State Changed From-To: suspended->open
Responsible Changed From-To: freebsd-doc->chris This is covered by my "SECURITY CONSIDERATIONS" man page work.
Responsible Changed From-To: chris->freebsd-doc With bugmeister hat on, reassign from inactive committer.
Recommend closing this ticket after 10+ years of inactivity.
This has been gathering dust for nearly 20 years. Is it still relevant?
I think this can be closed