Your message dated Tue, 11 Sep 2007 02:44:41 +0200
with message-id <[EMAIL PROTECTED]>
has caused the Debian Bug report #441478,
regarding libglpk0: security flaw buffer overflow in glplib05.c xvprintf
to be marked as having been forwarded to the upstream software
author(s) Andrew Makhorin <[EMAIL PROTECTED]>.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
package libglpk0
tags 441478 upstream
thanks
Andrew,
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?
Please, respect the Reply-To header in your reply, such that the discussion
is recorded in the Debian BTS (Bug Tracking System) at
http://bugs.debian.org/441478
Cheers,
Rafael
----- Forwarded message from "Peter T. Breuer" <[EMAIL PROTECTED]> -----
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
Reply-To: "Peter T. Breuer" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
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.
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, 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
[EMAIL PROTECTED]
http://lists.alioth.debian.org/mailman/listinfo/pkg-scicomp-devel
----- End forwarded message -----
--
Rafael
--- End Message ---