[Pkg-scicomp-devel] Bug#441478: [ptb at inv.it.uc3m.es: Bug#441478: libglpk0: security flaw buffer overflow in glplib05.c xvprintf]

[Andrew Makhorin]

Hi Rafael,

> The bug report below was filed against the GLPK package in Debian.
> Although the reported version is 4.20, the problem would also exist
> in 4.21. Could you please check this?

As I remember the previous bug report concerned one informational
message (from glp_simplex) not masked by msg_lev = GLP_MSG_OFF, and
that bug was fixed in 4.21.

> ----- Forwarded message from "Peter T. Breuer" <ptb at inv.it.uc3m.es> -----

> From: "Peter T. Breuer" <ptb at inv.it.uc3m.es>
> Subject: [Pkg-scicomp-devel] Bug#441478: libglpk0: security flaw buffer
> 	overflow in glplib05.c xvprintf
> Date: Mon, 10 Sep 2007 07:56:50 +0200
> To: Debian Bug Tracking System <submit at bugs.debian.org>
> Reply-To: "Peter T. Breuer" <ptb at inv.it.uc3m.es>, 441478 at bugs.debian.org
> Message-ID: <20070910055650.11738.65257.reportbug at betty.it.uc3m.es>

> Package: libglpk0
> Version: 4.20-1
> Severity: minor


> Looking through the code for a way to shut off the annoying messaged
> from lpx_adv_basis in the version of libglpk0 that is current for my
> distribution (a new version has been made available to unstable, but
> that's not me ...), I noticed the following in xvprintf of
> src/glplib05.c:

>   static void
>   xvprintf (const char *fmt, va_list arg)
>   {
>       char    buf[4000 + 1];
>       vsprintf (buf, fmt, arg);
>       xassert (strlen (buf) < sizeof (buf));          /* here! */
>       xputs (buf);
>       return;
>   }

> The assertion checks the length of the string in the current buffer
> AFTER having written it there. Too late, and ineffective anyway.

Thank you for your report.

However, this is not a bug, since buf cannot overflow; xvprintf is
not available on api level neither directly nor indirectly and used
internally only by glpk routines, which do not output messages long
enough to cause the overflow.

I agree that using vsnprintf would be more correct, however, it is
a relatively new function which until recently was unavailable on
some platform.

> 1) The buffer overflow has already occurred, if it has occurred at all,
>    so the check is notionally too late. One wants to check before
>    doing the vsprintf into the buffer, if anywhere.
   
>    Yes, it is likely that a buffer overflow seeks to alter the return
>    address on the stack,

It depends on implementation of C. Some implementations (I know one)
allocate automatic variables and the context info in different stacks.
Besides, in case of failure (which can never happen as I explained
above) xassert eventually would call the abort function, which does not
return. :)

> so a check in the same routine is not too late
>    for deetcting that, but one can perfectly easily write a string with
>    a zero half-way along (by writing a low integer, for example) that is
>    going to stop the strlen calculation within bounds, and a buffer
>    overflow attempt WILL write zeros.

> 2) In any case checking strlen(buf) will overrun the buffer in the
>    event the test fails, likely resulting in a violation of another
>    sort as it eventually runs into un-mapped memory areas. Only
>    luck stops it segfaulting.

> 3) The correct way to do this is to use vsnprintf. One wants

>       vsnprintf(buf, sizeof(buf), fmt, arg);

>    The sizeof(buf) is correct. Not sizeof(buf)-1 as the count by
>    vsnprintf includes a trailing zero. And in any case one can
>    check the number of bytes returned:

>       int n = vsnprintf(buf, sizeof(buf), fmt, arg);
>       xassert(n <= sizeof(buf));

> if one really wanted to do a check AFTER the event :), useless though
> that is.

> Best

> Peter


> -- System Information:
> Debian Release: lenny/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: i386 (i686)

> Kernel: Linux 2.6.15.3 (PREEMPT)
> Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
> Shell: /bin/sh linked to /bin/bash

> Versions of packages libglpk0 depends on:
> ii  libc6                     2.6.1-1+b1     GNU C Library: Shared libraries
> ii  libgmp3c2                 2:4.2.1+dfsg-5 Multiprecision arithmetic library

> libglpk0 recommends no packages.

> -- no debconf information



> _______________________________________________
> Pkg-scicomp-devel mailing list
> Pkg-scicomp-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-scicomp-devel

> ----- End forwarded message -----