Re: buffer overrun in zlib 1.1.4

From: Carlo Marcelo Arenas Belon (carenas@chasqui.lared.net.pe)
Date: 02/24/03

  • Next message: Thor Larholm: "Re: O UT LO OK E XPRE SS 6 .00 : broken" 
    Date: Mon, 24 Feb 2003 07:25:11 -0500 (PET)
From: Carlo Marcelo Arenas Belon <carenas@chasqui.lared.net.pe>
To: Richard Kettlewell <rjk@greenend.org.uk>

    > 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 :

      http://www.ijs.si/software/snprintf/

    regards,

    Carlo

    Relevant Pages

    • Platform independent allocating sprintf (was Re: buffer overrun
      ... >> vsnprintf() instead of vsprintf, but this is not enabled by default, ... > vsprintf if the UNIX flavor did not support snprintf. ... > MUA) and has a very liberal license. ... you can "special case" some of the most common % formatting ...
      (Bugtraq)
    • Re: vsprintf without vsnprintf
      ... I'm on a platform that has vsprintf but not vsnprintf. ... Is there anyway I can limit vsprintf or know in advance the required buffer ... Valgrind doesn't find overruns on automatic ...
      (comp.lang.c)
    • Re: vsprintf without vsnprintf
      ... I'm on a platform that has vsprintf but not vsnprintf. ... I suspect the former function is causing a buffer overflow but I've been unable to prove it so far. ... Is there anyway I can limit vsprintf or know in advance the required buffer size ?!? ... va_list arg) { ...
      (comp.lang.c)
    • Re: Query regarding thread safety of few libc stdio functions
      ... >Which ensures that they are thread safe. ... >Why is the same case not followed for eg with vsnprintf or vsprintf ... vsnprintf and vsprintf use a on stack FILE structure, ...
      (freebsd-current)