> 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.
the configure script on zlib is not generated by autoconf and is optional
when building; therefore there is no config.h, and the included file
"zconf.h" that is the one used for system related configuration is static.
something interesting though, is that the preprocessor variables being
tested are HAVE_* instead of HAS_* (HAS_vsnprintf and HAS_snprintf), as
the ones found on gzio.c, what could help to explain why it is not
documented, neither tested for.
from the Changelog it seems those functions were added on version 1.0.6
(Jan 19, 1998) by Roland Giersig and Kevin Ruland, and probably they never
included the test on configure for that.
> Even if it was documented, tested for, or whatever, it is unclear what
> platforms without vsnprintf() are supposed to do. Put up with the
> security hole, perhaps.
from the code it seems that they are supposed to use vsprintf (on an
ANSI C environment) or sprintf (if not ANSI C).
on any case, long strings will be silently truncated and overflows are
possible as the one you coded
> Finally, with HAS_vsnprintf defined, long strings will be silently
> truncated (and this isn't documented anywhere). Unexpected truncation
> of strings can have security implications too; I seem to recall that a
> popular MTA had trouble with over-long HELO strings for instance.
the attached patch fixes both of the problems, even if it breaks on
systems with a broken [v]snprintf (any one yet?) and that could be
considered a prerequisite for building, probably using a custom made
[v]snprintf implementation like the one on :
> vsnprintf() instead of vsprintf(), but this is not enabled by default,
> not tested for by the configure script, and not documented.
the configure script on zlib is not generated by autoconf and is optional
when building; therefore there is no config.h, and the included file
"zconf.h" that is the one used for system related configuration is static.
something interesting though, is that the preprocessor variables being
tested are HAVE_* instead of HAS_* (HAS_vsnprintf and HAS_snprintf), as
the ones found on gzio.c, what could help to explain why it is not
documented, neither tested for.
from the Changelog it seems those functions were added on version 1.0.6
(Jan 19, 1998) by Roland Giersig and Kevin Ruland, and probably they never
included the test on configure for that.
> Even if it was documented, tested for, or whatever, it is unclear what
> platforms without vsnprintf() are supposed to do. Put up with the
> security hole, perhaps.
from the code it seems that they are supposed to use vsprintf (on an
ANSI C environment) or sprintf (if not ANSI C).
on any case, long strings will be silently truncated and overflows are
possible as the one you coded
> Finally, with HAS_vsnprintf defined, long strings will be silently
> truncated (and this isn't documented anywhere). Unexpected truncation
> of strings can have security implications too; I seem to recall that a
> popular MTA had trouble with over-long HELO strings for instance.
the attached patch fixes both of the problems, even if it breaks on
systems with a broken [v]snprintf (any one yet?) and that could be
considered a prerequisite for building, probably using a custom made
[v]snprintf implementation like the one on :
http://www.ijs.si/software/snprintf/
regards,
Carlo
[ reply ]