Re: [Cooker] zlib malloc issue
On Wed, Mar 13, 2002 at 04:14:18PM +0100, Han wrote: > http://www.linux-mandrake.com/cgi-bin/cvsweb.cgi/SPECS/zlib/ > > Somehow I don't believe you. The reason a lot of this confusion occurs is because a lot of time relapse of the existence of the bug is embargoed in order to give all the vendors a chance to update. As a result patches to cooker often go in without being very specific about the fact that they fixed the security bug. -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org What difference does it make to the dead, the orphans, and the homeless, whether the mad destruction is wrought under the name of totalitarianism or the holy name of liberty and democracy? - Ghandi
Re: [Cooker] zlib malloc issue
Frederic Lepied wrote: > [...] > > I'm writing this here, because I did not see any postings to this > > issue 'til now (maybe I missed something) and the zlib on my > > mirror still is version zlib-1.1.3-19mdk.src.rpm. > > > > I hope you will find a good solution. > > > > All the cooker packages already contain the fix for this problem. > -- > Fred - May the source be with you I found the patch now too. Sorry, I got confused by the old version number. I am now on the security-announce list, to avoid such confusion in the future. ;) cu Michi
Re: [Cooker] zlib malloc issue
Han ([EMAIL PROTECTED]) wrote: > Frederic Lepied ([EMAIL PROTECTED]) wrote: > > Michael Riss <[EMAIL PROTECTED]> writes: > > > > > > it went over several newstickers yesterday, there is a bug in > > > zlib-1.1.3. Certain input confuses the memory management of zlib, > > > which leads to crashes or worse, might lead to the execution of > > > arbitrary code. > > > > All the cooker packages already contain the fix for this problem. > > http://www.linux-mandrake.com/cgi-bin/cvsweb.cgi/SPECS/zlib/ > > Somehow I don't believe you. Mea Culpa: zlib-1.1.3-zfree.patch is the patch. It has been included in cooker for quite sometime now. Groetjes, Han. -- http://www.xs4all.nl/~hanb/software
Re: [Cooker] zlib malloc issue
Sign up for the Mandrake Security Announce list: http://www.linux-mandrake.com/en/flists.php3 --- Michael Riss <[EMAIL PROTECTED]> wrote: > Hello > > it went over several newstickers yesterday, there is > a bug > in zlib-1.1.3. Certain input confuses the memory > management > of zlib, which leads to crashes or worse, might lead > to the > execution of arbitrary code. > > The full description is on: > > http://www.gzip.org/zlib/advisory-2002-03-11.txt > > There is a new version zlib-1.1.4, which fixes this > problem. > Unfortunatly there are some programs, which are > statically linked > to zlib, they have to be recompiled too. > For a list of programs linking to zlib: > > http://www.gzip.org/zlib/apps.html > > Redhat has allready patches, including a patched > kernel > (kernel ppp compression is also using zlib): > > http://www.linuxsecurity.com/advisories/redhat_advisory-1963.html > > This issue might be important enough for 8.2 final, > although > many packages will be touched. Fixing it via patches > leaves a > bad taste, you buy the latest Mandrake and the first > thing to do > is updating a bunch of RPMs. > > I'm writing this here, because I did not see any > postings to this > issue 'til now (maybe I missed something) and the > zlib on my > mirror still is version zlib-1.1.3-19mdk.src.rpm. > > I hope you will find a good solution. > > > cu > Michi > __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/
Re: [Cooker] zlib malloc issue
Frederic Lepied ([EMAIL PROTECTED]) wrote: > Michael Riss <[EMAIL PROTECTED]> writes: > > > > it went over several newstickers yesterday, there is a bug in > > zlib-1.1.3. Certain input confuses the memory management of zlib, > > which leads to crashes or worse, might lead to the execution of > > arbitrary code. > > All the cooker packages already contain the fix for this problem. http://www.linux-mandrake.com/cgi-bin/cvsweb.cgi/SPECS/zlib/ Somehow I don't believe you. Groetjes, Han. -- http://www.xs4all.nl/~hanb/software
Re: [Cooker] zlib malloc issue
Michael Riss <[EMAIL PROTECTED]> writes: > Hello > > it went over several newstickers yesterday, there is a bug > in zlib-1.1.3. Certain input confuses the memory management > of zlib, which leads to crashes or worse, might lead to the > execution of arbitrary code. > [...] > > I'm writing this here, because I did not see any postings to this > issue 'til now (maybe I missed something) and the zlib on my > mirror still is version zlib-1.1.3-19mdk.src.rpm. > > I hope you will find a good solution. > All the cooker packages already contain the fix for this problem. -- Fred - May the source be with you
Re: [Cooker] zlib malloc issue
"Kevin Krumwiede" <[EMAIL PROTECTED]> writes:
> For various reasons, many packages (including the kernel) have
> chunks of code copied from zlib rather than statically or
> dynamically linking with it, so it could be quite a while before
> this bug is eradicated.
the kernel cannot use a shared lib and has special needs for ppp
{de,}compression.
RE: [Cooker] zlib malloc issue
>From malloc(3):
Recent versions of Linux libc (later than 5.4.23) and GNU
libc (2.x) include a malloc implementation which is tun
able via environment variables. When MALLOC_CHECK_ is
set, a special (less efficient) implementation is used
which is designed to be tolerant against simple errors,
such as double calls of free() with the same argument, or
overruns of a single byte (off-by-one bugs). Not all such
errors can be proteced against, however, and memory leaks
can result. If MALLOC_CHECK_ is set to 0, any detected
heap corruption is silently ignored; if set to 1, a diag
nostic is printed on stderr; if set to 2, abort() is
called immediately. This can be useful because otherwise
a crash may happen much later, and the true cause for the
problem is then very hard to track down.
Setting MALLOC_CHECK_ in /etc/profile might be a good fix until all packages
are updated. It might hurt performance a little but probably not
significantly on a workstation. The following program demonstrates.
(WARNING: This program deliberately tries to corrupt the heap):
#include
#include
int main(int argc, char* argv[]) {
void* foo = malloc(16);
free(foo);
free(foo);
printf("Program ran to completion.\n");
}
Without MALLOC_CHECK_ set it segfaults before the printf. With
MALLOC_CHECK_=0 it does not segfault. With MALLOC_CHECK_=1 it prints an
annoying error message but proceeds to the printf. With MALLOC_CHECK_=2 it
prints "Abort" and terminates before the printf.
For various reasons, many packages (including the kernel) have chunks of
code copied from zlib rather than statically or dynamically linking with it,
so it could be quite a while before this bug is eradicated.
Krum
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Riss
> Sent: Wednesday, March 13, 2002 6:20 AM
> To: [EMAIL PROTECTED]
> Subject: [Cooker] zlib malloc issue
>
>
> Hello
>
> it went over several newstickers yesterday, there is a bug
> in zlib-1.1.3. Certain input confuses the memory management
> of zlib, which leads to crashes or worse, might lead to the
> execution of arbitrary code.
>
> The full description is on:
>
> http://www.gzip.org/zlib/advisory-2002-03-11.txt
>
> There is a new version zlib-1.1.4, which fixes this problem.
> Unfortunatly there are some programs, which are statically linked
> to zlib, they have to be recompiled too.
> For a list of programs linking to zlib:
>
> http://www.gzip.org/zlib/apps.html
>
> Redhat has allready patches, including a patched kernel
> (kernel ppp compression is also using zlib):
>
> http://www.linuxsecurity.com/advisories/redhat_advisory-1963.html
>
> This issue might be important enough for 8.2 final, although
> many packages will be touched. Fixing it via patches leaves a
> bad taste, you buy the latest Mandrake and the first thing to do
> is updating a bunch of RPMs.
>
> I'm writing this here, because I did not see any postings to this
> issue 'til now (maybe I missed something) and the zlib on my
> mirror still is version zlib-1.1.3-19mdk.src.rpm.
>
> I hope you will find a good solution.
>
>
> cu
> Michi
>
