From mike@urgle.com  Mon Apr  2 02:48:42 2001
Return-Path: <mike@urgle.com>
Received: from lindt.urgle.com (lindt.urgle.com [62.49.202.23])
	by hub.freebsd.org (Postfix) with ESMTP id 83AAB37B718
	for <FreeBSD-gnats-submit@freebsd.org>; Mon,  2 Apr 2001 02:48:41 -0700 (PDT)
	(envelope-from mike@urgle.com)
Received: from mike by lindt.urgle.com with local (Exim 3.16 #1)
	id 14k0wy-0006UD-00
	for FreeBSD-gnats-submit@freebsd.org; Mon, 02 Apr 2001 10:48:40 +0100
Message-Id: <E14k0wy-0006UD-00@lindt.urgle.com>
Date: Mon, 02 Apr 2001 10:48:40 +0100
From: Mike Bristow <mike@urgle.com>
Reply-To: mike@urgle.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: format string warnings in man pages.
X-Send-Pr-Version: 3.2

>Number:         26286
>Category:       docs
>Synopsis:       *printf(3) etc should gain format string warnings
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-doc
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Mon Apr 02 02:50:00 PDT 2001
>Closed-Date:    
>Last-Modified:  Thu Aug 26 02:26:06 GMT 2004
>Originator:     Mike Bristow
>Release:        FreeBSD 4.3-BETA i386
>Organization:
>Environment:

RELENG_4 (sadly, I don't have a -current box atm)

>Description:

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.

>How-To-Repeat:

$ man 3 printf

>Fix:

This patch (should) apply to a -stable tree, I don't have a -current box
at the moment :(

Index: share/man/man3/stdarg.3
===================================================================
RCS file: /upstream-repositories/freebsd.org/src/share/man/man3/stdarg.3,v
retrieving revision 1.4.2.2
diff -u -r1.4.2.2 stdarg.3
--- share/man/man3/stdarg.3	2001/03/06 19:08:09	1.4.2.2
+++ share/man/man3/stdarg.3	2001/03/29 15:48:07
@@ -120,7 +120,7 @@
 .Fa type
 is not compatible with the type of the actual next argument
 (as promoted according to the default argument promotions),
-random errors will occur.
+random errors will occur, which might lead to a security risk.
 .Pp
 The first use of the
 .Fn va_arg
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
 The output is terminated by a newline character.
 .Pp
 The
Index: lib/libc/gen/setproctitle.3
===================================================================
RCS file: /upstream-repositories/freebsd.org/src/lib/libc/gen/setproctitle.3,v
retrieving revision 1.16.2.2
diff -u -r1.16.2.2 setproctitle.3
--- lib/libc/gen/setproctitle.3	2000/12/08 13:49:24	1.16.2.2
+++ lib/libc/gen/setproctitle.3	2001/03/29 15:48:07
@@ -39,13 +39,17 @@
 .Xr ps 1
 command.
 .Pp
-The title is set from the executable's name, followed by the
-result of a
-.Xr printf 3
-style expansion of the arguments as specified by the
+If 
+.Va fmt 
+is not NULL, then the title is set from the executable's name,
+followed by the result of treating
 .Va fmt
-argument.
-If the
+as a format string that specifies how subsequent arguments are
+converted, in the same was as
+.Xr printf 3 .
+If the format string specifies arguments that do not exist, or it
+specifies a type different from that actually given, random errors,
+that could cause a security risk, may occur.  If the
 .Va fmt
 argument begins with a
 .Dq -
Index: lib/libc/gen/syslog.3
===================================================================
RCS file: /upstream-repositories/freebsd.org/src/lib/libc/gen/syslog.3,v
retrieving revision 1.9.2.4
diff -u -r1.9.2.4 syslog.3
--- lib/libc/gen/syslog.3	2001/03/06 16:45:55	1.9.2.4
+++ lib/libc/gen/syslog.3	2001/03/29 15:48:07
@@ -48,9 +48,9 @@
 .Fd #include <syslog.h>
 .Fd #include <varargs.h>
 .Ft void
-.Fn syslog "int priority" "const char *message" "..."
+.Fn syslog "int priority" "const char *fmt" "..."
 .Ft void
-.Fn vsyslog "int priority" "const char *message" "va_list args"
+.Fn vsyslog "int priority" "const char *fmt" "va_list args"
 .Ft void
 .Fn openlog "const char *ident" "int logopt" "int facility"
 .Ft void
@@ -60,33 +60,34 @@
 .Sh DESCRIPTION
 The
 .Fn syslog
-function
-writes
-.Fa message
-to the system message logger.
+function writes a message to the system message logger.
 The message is then written to the system console, log files,
 logged-in users, or forwarded to other machines as appropriate.
 (See
 .Xr syslogd 8 . )
 .Pp
-The message is identical to a
-.Xr printf 3
-format string, except that
+The message is created by treating
+.Va fmt
+as a format string that specifies how subsequent arguments are
+converted, in the same was as
+.Xr printf 3 ,
+with an additional convertion specifier of
 .Ql %m
-is replaced by the current error
-message.
-(As denoted by the global variable
+which is replaced by the current error message.  (As denoted by
+the global variable
 .Va errno ;
 see
 .Xr strerror 3 . )
-A trailing newline is added if none is present.
+If the format string specifies arguments that do not exist, or it
+specifies a type different from that actually given, random errors,
+that could cause a security risk, may occur.  A trailing newline
+is added if none is present.
 .Pp
 The
 .Fn vsyslog
-function
-is an alternate form in which the arguments have already been captured
-using the variable-length argument facilities of
-.Xr varargs 3 .
+function is an alternate form in which the arguments have already
+been captured using the variable-length argument facilities of
+.Xr stdarg 3 .
 .Pp
 The message is tagged with
 .Fa priority .
Index: lib/libc/stdio/printf.3
===================================================================
RCS file: /upstream-repositories/freebsd.org/src/lib/libc/stdio/printf.3,v
retrieving revision 1.17.2.5
diff -u -r1.17.2.5 printf.3
--- lib/libc/stdio/printf.3	2001/03/06 16:46:01	1.17.2.5
+++ lib/libc/stdio/printf.3	2001/03/29 15:48:07
@@ -170,7 +170,11 @@
 the character
 .Cm % .
 The arguments must correspond properly (after type promotion)
-with the conversion specifier.
+with the conversion specifier.  If they do not random errors,
+which could cause a security risk, may occur.  In particular,
+user-supplied data should never be included in the format string
+without checking that it is safe (eg, does not contain %s
+and other character sequences with special meaning).
 After the
 .Cm % ,
 the following appear in sequence:
>Release-Note:
>Audit-Trail:

From: Dima Dorfman <dima@unixfreak.org>
To: mike@urgle.com
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: docs/26286: format string warnings in man pages. 
Date: Mon, 02 Apr 2001 18:38:26 -0700

 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

From: Mike Bristow <mike@urgle.com>
To: Dima Dorfman <dima@unixfreak.org>
Cc: mike@urgle.com, FreeBSD-gnats-submit@freebsd.org
Subject: Re: docs/26286: format string warnings in man pages.
Date: Tue, 3 Apr 2001 09:48:38 +0100

 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  

From: Dima Dorfman <dima@unixfreak.org>
To: Bengt Richter <bokr@accessone.com>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: docs/26286: format string warnings in man pages. 
Date: Tue, 03 Apr 2001 18:15:57 -0700

 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 
State-Changed-By: nik 
State-Changed-When: Wed Jan 9 05:35:04 PST 2002 
State-Changed-Why:  
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. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=26286 
State-Changed-From-To: suspended->open 
State-Changed-By: nik 
State-Changed-When: Wed Jan 9 05:36:50 PST 2002 
State-Changed-Why:  


http://www.FreeBSD.org/cgi/query-pr.cgi?pr=26286 
Responsible-Changed-From-To: freebsd-doc->chris 
Responsible-Changed-By: chris 
Responsible-Changed-When: Thu Jun 13 16:43:23 PDT 2002 
Responsible-Changed-Why:  
This is covered by my "SECURITY CONSIDERATIONS" man page work. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=26286 
Responsible-Changed-From-To: chris->freebsd-doc 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Thu Aug 26 02:25:44 GMT 2004 
Responsible-Changed-Why:  
With bugmeister hat on, reassign from inactive committer. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=26286 
>Unformatted:
