Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Jun 2002 12:10:55 +0200
From:      Martin Faxer <gmh003532@brfmasthugget.se>
To:        Chris Costello <chris@FreeBSD.org>
Cc:        cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/lib/libc/stdio printf.3
Message-ID:  <20020614101055.GA576@lockdown.spectrum.fearmuffs.net>
In-Reply-To: <200206132335.g5DNZNT14936@freefall.freebsd.org>
References:  <200206132335.g5DNZNT14936@freefall.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2002.06.13 16:35:22 +0000, Chris Costello wrote:
> chris       2002/06/13 16:35:22 PDT
> 
>   Modified files:
>     lib/libc/stdio       printf.3 
>   Log:
>   Include information on the dangers of passing a user-supplied string as
>   a format string.  This will later on be changed to a reference to the
>   FreeBSD Security Architecture after it has been committed.

i must say, that i'm not really happy with your change...
(quoting the patch:)

+The
+.Fn printf
+and
+.Fn vprintf

this makes it sound as if only printf() and vprintf() are vulnerable
when in fact the whole printf family of functions are susceptible
to exploits.  even if sprintf() et al. call vprintf() somewhere down the
line i don't see your reasoning for changing my "The .Nm family
of functions" to just printf() and vprintf().

+functions are also easily misused in a manner allowing malicious users
+to arbitrarily change a running program's functionality by either
+causing the program to print potentially sensitive data
+.Dq "left on the stack,"
+or causing it to generate a memory fault or bus error
+by dereferencing an invalid pointer.

when you say 'either' it sounds like there are only 2 possible
outcomes; reading data off the stack or crashing the program by
generating a protection fault or bus error.
in my opinion this ignores the most common (and perhaps the most
'lethal') exploitation method which uses the %n format specifier
to overwrite important data (like return addresses.)

+.Pp
+Never, under any circumstances pass a string obtained from the network,
+a file, or any user as a format string to a
+.Fn printf
+or
+.Fn sprintf
+function.

this can in my opinion be changed to "always pass a constant format
string", since i don't see much use for passing a variable string
if it can't be obtained from the network, a file or any user's input.
i don't feel too strongly about this though :)
(i just think the general recommendation should be to _always_
 include a constant format string, since that effectively avoids
 all kinds of attacks.  not passing a constant format string is
 kind of like "begging for it"...  in the case that the programmer
 _really_ needs a variable format string i think he will have got
 enough experience to know that he must be very careful when generating
 it and do all kinds of "sanity checks" for weird format specifiers etc.)

+.Xc
+.Ec
 .Sh SEE ALSO
 .Xr printf 1 ,
 .Xr scanf 3 ,

>   
>   PR:             docs/39320
>   Sposnored by:   DARPA, NAI Labs
>   
>   Revision  Changes    Path
>   1.39      +21 -0     src/lib/libc/stdio/printf.3

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020614101055.GA576>