91548 2003-02-25 00:57 /62 rader/ Forrest J. Cavalier III <forrest@mibsoftware.com>
Importerad: 2003-02-25 00:57 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Externa svar till: forrest@mibsoftware.com
Mottagare: Bugtraq (import) <3658>
Ärende: Platform independent allocating sprintf (was Re: buffer overrun
------------------------------------------------------------
Thamer Al-Harbash <tmh@whitefang.com> wrote
> On Sat, 22 Feb 2003, Richard Kettlewell wrote:
>
> > There is an internal #define (HAS_vsnprintf) that causes it to use
> > vsnprintf() instead of vsprintf(), but this is not enabled by default,
> > not tested for by the configure script, and not documented.
>
> This is a fairly normal (and somewhat frightening) practice I've
> seen in several popular packages.
>
> Last I checked ISC dhcp has a #define for vsnprintf to be
> vsprintf if the UNIX flavor did not support snprintf.
>
[snip]
>
> I know that Ted Lemon, the primary author, is aware this. I've
> mentioned it to him a while ago. I am also not aware of this
> causing any security holes; although I honestly have not given
> his source a security audit.
>
> There are replacement 'snprintf' packages which avoid
> this. Patrick Powell's replacement is used in Mutt (a popular
> MUA) and has a very liberal license.
If you can't use the allocating vasprintf() and care about security,
tmpfile() and vfprintf() are available on just about every
platform, including Windows.
You have to trust tmpfile() and have a vfprintf() which returns
a negative integer on filesystem errors (and it will, if it
complies with IEEE Std 1003.1-2001)
For speedup, you can "special case" some of the most common %
formatting (%%, %s, %d, and %u) and use the tmpfile() strategy only
when there are field width specifiers and unrecognized format
specifiers. When you do that, the performance is usually acceptable,
and you can still use all of the "special" formatting you often get
with localized fprintf()s.
Librock has reusable code which uses just that strategy to implement a
platform-independent "printf into an allocated string". Docs and
source at:
http://www.mibsoftware.com/librock/text/vastrprintf.htm
This function follows the typical easy-to-reuse semantics
and licensing of the librock_astr functions:
char *asz = 0; /* Must initialize to 0! */
librock_astrprintf(&asz,"This is a test %s\n",pszLongString);
. . .
librock_astrcat(&asz,"\nAppending another long string....");
. . .
librock_astrfree(&asz);
(The librock source code is Free. No cost. BSD-ish license with no
advertising clause.)
Hope it helps!
Forrest Cavalier III, owner Mib Software
(91548) /Forrest J. Cavalier III <forrest@mibsoftware.com>/(Ombruten)
Kommentar i text 91696 av James Antill <james-bugtraq@and.org>
91696 2003-02-25 19:31 /72 rader/ James Antill <james-bugtraq@and.org>
Importerad: 2003-02-25 19:31 av Brevbäraren
Extern mottagare: Forrest J. Cavalier III <forrest@mibsoftware.com>
Mottagare: Bugtraq (import) <3678>
Kommentar till text 91548 av Forrest J. Cavalier III <forrest@mibsoftware.com>
Ärende: Re: Platform independent allocating sprintf (was Re: buffer overrun
------------------------------------------------------------
"Forrest J. Cavalier III" <forrest@mibsoftware.com> writes:
> Thamer Al-Harbash <tmh@whitefang.com> wrote
>
> > On Sat, 22 Feb 2003, Richard Kettlewell wrote:
> >
> > > There is an internal #define (HAS_vsnprintf) that causes it to use
> > > vsnprintf() instead of vsprintf(), but this is not enabled by default,
> > > not tested for by the configure script, and not documented.
> >
> > This is a fairly normal (and somewhat frightening) practice I've
> > seen in several popular packages.
Fairly normal, for the same group of people that use fixed buffers
everywhere.
> > Last I checked ISC dhcp has a #define for vsnprintf to be
> > vsprintf if the UNIX flavor did not support snprintf.
> >
> [snip]
> >
> > I know that Ted Lemon, the primary author, is aware this. I've
> > mentioned it to him a while ago. I am also not aware of this
> > causing any security holes; although I honestly have not given
> > his source a security audit.
ISC doesn't write great code, I'm shocked.
> > There are replacement 'snprintf' packages which avoid
> > this. Patrick Powell's replacement is used in Mutt (a popular
> > MUA) and has a very liberal license.
>
> If you can't use the allocating vasprintf() and care about security,
> tmpfile() and vfprintf() are available on just about every
> platform, including Windows.
The very simple way to do it is to use vasprintf() or vsnprintf(),
and hack vsnprintf() for those platforms that still don't have
vsnprintf() (actually it's often better to just go straight for
vsnprintf() do to the non-std. of asprintf(), for instance the glibc
error case is braindead).
However that only solves some of the problem, all printf()
implementations aren't equal. For a comparison of some portable
printf() functions (of varying quality) see the bottom section of...
http://www.and.org/vstr/comparison.html
...although at least a couple of the string libraries there also
contain portable printf() like (again of varying quality) functions as
part of their API.
> For speedup, you can "special case" some of the most common % formatting
> (%%, %s, %d, and %u) and use the tmpfile() strategy only when there are
> field width specifiers and unrecognized format specifiers. When you
> do that, the performance is usually acceptable, and you can still use
> all of the "special" formatting you often get with localized fprintf()s.
>
> Librock has reusable code which uses just that strategy to implement a
> platform-independent "printf into an allocated string". Docs and
> source at:
> http://www.mibsoftware.com/librock/text/vastrprintf.htm
Well apart from the non-portability, the error checking is wrong on
the asprintf() calls so you'll SEGV if malloc() fails.
--
# James Antill -- james@and.org
:0:
* ^From: .*james@and\.org
/dev/null
(91696) /James Antill <james-bugtraq@and.org>/------