8126589 2002-03-11 22:00 +0100 /96 rader/ Jean-loup Gailly <jloup@gzip.org>
Sänt av: joel@lysator.liu.se
Importerad: 2002-03-12 04:26 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Externa svar till: jloup@gzip.org
Mottagare: Bugtraq (import) <21362>
Ärende: security problem fixed in zlib 1.1.4
------------------------------------------------------------
From: Jean-loup Gailly <jloup@gzip.org>
To: bugtraq@securityfocus.com
Message-ID: <15501.6885.557609.342477@kerla.poseidon-tech.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Zlib Advisory 2002-03-11 zlib Compression Library Corrupts malloc
Data Structures via Double Free
Original release date: March 11, 2002
Last revised: March 11, 2002
Source: This advisory is based on a CERT advisory written
by Jeffrey P. Lanza. See original on http://www.cert.org
Systems Affected
* Any software that is linked against zlib 1.1.3 or earlier
* Any data compression library derived from zlib 1.1.3 or earlier
Overview
There is a vulnerability in the zlib shared library that may introduce
vulnerabilities into any program that includes zlib. This
vulnerability has been assigned a CVE candidate name of CAN-2002-0059
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0059
I. Description
There is a vulnerability in the decompression algorithm used by
the popular zlib compression library. If an attacker is able
to pass a specially-crafted block of invalid compressed data to a
program that includes zlib, the program's attempt to decompress
the crafted data can cause the zlib routines to corrupt the
internal data structures maintained by malloc.
The vulnerability results from a programming error that causes
segments of dynamically allocated memory to be released more than once
(aka. "double-freed"). Specifically, when inftrees.c:huft_build()
encounters the crafted data, it returns an unexpected Z_MEM_ERROR to
inftrees.c:inflate_trees_dynamic(). When a subsequent call is made to
infblock.c:inflate_blocks(), the inflate_blocks function tries to free
an internal data structure a second time.
Because this vulnerability interferes with the proper allocation
and de-allocation of dynamic memory, it may be possible for an
attacker to influence the operation of programs that include
zlib. In most circumstances, this influence will be limited to
denial of service or information leakage, but it is theoretically
possible for an attacker to insert arbitrary code into a
running program. This code would be executed with the permissions
of the vulnerable program.
II. Impact
This vulnerability may introduce vulnerabilities into any program that
includes the affected library. Depending upon how and where the zlib
routines are called from the given program, the resulting
vulnerability may have one or more of the following impacts: denial of
service, information leakage, or execution of arbitrary code.
III. Solution
Upgrade your version of zlib
The maintainers of zlib have released version 1.1.4 to address
this vulnerability. Any software that is linked against or
derived from an earlier version of zlib should be upgraded
immediately. The latest version of zlib is available at
http://www.zlib.org
The md5 sums of the source archives are:
abc405d0bdd3ee22782d7aa20e440f08 zlib-1.1.4.tar.gz
ea16358be41384870acbdc372f9db152 zlib-1.1.4.tar.bz2
IV. Acknowledgments
Thanks to Owen Taylor and other people at Redhat Inc. for the
reporting and research of this vulnerability.
This document is available from
http://www.gzip.org/zlib/advisory-2002-03-11.txt
The public PGP key of zlib author Jean-loup Gailly is available from
http://www.gzip.org/zlib/jloup.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8jRnX2aJ9JQGWcacRAiBcAJ9LiYJm/Nk4EbnD6qBJUsHUmgrk/QCdG5br
M8WeqzcAwikwlEFSPHpt790=
=0/cN
-----END PGP SIGNATURE-----
(8126589) /Jean-loup Gailly <jloup@gzip.org>/(Ombruten)
Kommentar i text 8130440 av Neil W Rickert <rickert+bt@cs.niu.edu>
8130440 2002-03-11 19:13 -0600 /28 rader/ Neil W Rickert <rickert+bt@cs.niu.edu>
Sänt av: joel@lysator.liu.se
Importerad: 2002-03-12 20:12 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <21369>
Kommentar till text 8126589 av Jean-loup Gailly <jloup@gzip.org>
Ärende: Re: security problem fixed in zlib 1.1.4
------------------------------------------------------------
From: Neil W Rickert <rickert+bt@cs.niu.edu>
To: bugtraq@securityfocus.com
Message-ID: <12790.1015895592@euclid.cs.niu.edu>
Jean-loup Gailly <jloup@gzip.org> wrote:
>Zlib Advisory 2002-03-11
>zlib Compression Library Corrupts malloc Data Structures via Double Free
A quick note.
Checking the source code from ssh.com, it appears that ssh-1.2.33
comes with included zlib-1.0.4, and ssh-3.1.0 comes with included
zlib-1.1.3 .
Possibly both are vulnerable.
With OpenSSH, you supply a separately installed zlib. Presumably
versions compiled before today, including those built to handle
the channel.c problem may be vulnerable to the zlib problem.
It would be a sensible idea for people who compiled OpenSSH-3.1p1
last week to install the new zlib and rebuild OpenSSH.
-NWR
(8130440) /Neil W Rickert <rickert+bt@cs.niu.edu>/--
8132202 2002-03-11 21:36 -0500 /29 rader/ hologram <holo@brained.org>
Sänt av: joel@lysator.liu.se
Importerad: 2002-03-13 05:29 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern mottagare: vulnwatch@vulnwatch.org
Mottagare: Bugtraq (import) <21392>
Ärende: zlibscan : script to find suid binaries possibly affected by zlib vulnerability
------------------------------------------------------------
From: hologram <holo@brained.org>
To: <bugtraq@securityfocus.com>, <vulnwatch@vulnwatch.org>
Message-ID: <Pine.BSO.4.33.0203112131260.11537-100000@brained.org>
Hi,
The following is a quick shell script to find suid binaries that are
potentially affected by the zlib vulnability (i.e., those dynamically
linked).
-[snip]-----------------------------------------------------------------
#!/bin/sh
# zlibscan by hologram <holo@brained.org>
# This will scan to find suid binaries potentially affected by the zlib
# vulnerablity. These are important directories for the Linux system,
# try different ones for other systems (i.e., /usr/etc, /usr/local/bin).
(ldd `find /bin -perm -4000` 2> /dev/null | grep zlib) > zlib.lst
(ldd `find /sbin -perm -4000` 2> /dev/null | grep zlib) >> zlib.lst
(ldd `find /usr/bin -perm -4000` 2> /dev/null | grep zlib) >> zlib.lst
(ldd `find /etc -perm -4000` 2> /dev/null | grep zlib) >> zlib.lst
(ldd `find /var -perm -4000` 2> /dev/null | grep zlib) >> zlib.lst
-[snap]-----------------------------------------------------------------
- hologram
(8132202) /hologram <holo@brained.org>/-------------
Kommentar i text 8136444 av Adam <adam@cfar.umd.edu>
Kommentar i text 8137097 av Florian Weimer <Weimer@CERT.Uni-Stuttgart.DE>
Kommentar i text 8137194 av Jean-loup Gailly <jloup@gzip.org>
Kommentar i text 8137243 av Dimitry Andric <dim@xs4all.nl>
Kommentar i text 8137851 av Guy Poizat <poizat@partsonline.fr>
8136444 2002-03-12 22:14 -0500 /42 rader/ Adam <adam@cfar.umd.edu>
Sänt av: joel@lysator.liu.se
Importerad: 2002-03-13 21:26 av Brevbäraren
Extern mottagare: hologram <holo@brained.org>
Extern kopiemottagare: bugtraq@securityfocus.com
Extern kopiemottagare: vulnwatch@vulnwatch.org
Mottagare: Bugtraq (import) <21402>
Kommentar till text 8132202 av hologram <holo@brained.org>
Ärende: Re: zlibscan : script to find suid binaries possibly affected by zlib vulnerability
------------------------------------------------------------
From: Adam <adam@cfar.umd.edu>
To: hologram <holo@brained.org>
Cc: <bugtraq@securityfocus.com>, <vulnwatch@vulnwatch.org>
Message-ID: <Pine.GSO.4.33.0203122207380.8239-100000@chia.umiacs.umd.edu>
> #!/bin/sh
> (ldd `find /bin -perm -4000` 2> /dev/null | grep zlib) > zlib.lst
> (ldd `find /sbin -perm -4000` 2> /dev/null | grep zlib) >> zlib.lst
> (ldd `find /usr/bin -perm -4000` 2> /dev/null | grep zlib) >> zlib.lst
> (ldd `find /etc -perm -4000` 2> /dev/null | grep zlib) >> zlib.lst
> (ldd `find /var -perm -4000` 2> /dev/null | grep zlib) >> zlib.lst
few comments:
1) wasn't the library called 'libz' instead of 'zlib'? at least
so it is called on my system:
# rpm -q -l zlib
/usr/lib/libz.so.1
2) ldd is just shell wrapper, so for system wide search it is more
efficent to call ld-linux directly (at least for linux systems)
for example
# ldd /sbin/askrunlevel | grep libz
libz.so.1 => /usr/lib/libz.so.1 (0x400fa000)
# /lib/ld-linux.so.2 --list /sbin/askrunlevel | grep libz
libz.so.1 => /usr/lib/libz.so.1 (0x400e4000)
3) you are forgetting that library can call in turn call other
libraries. so searching binary directories is not enough. you have
to, at least, search library directories as well. for example:
# /lib/ld-linux.so.2 --list /usr/lib/kcalc.so | grep libz
libz.so.1 => /usr/lib/libz.so.1 (0x40be3000)
-- Adam http://www.eax.com The Supreme Headquarters of the 32
bit registers
(8136444) /Adam <adam@cfar.umd.edu>/------(Ombruten)
8137097 2002-03-13 19:53 +0100 /237 rader/ Florian Weimer <Weimer@CERT.Uni-Stuttgart.DE>
Sänt av: joel@lysator.liu.se
Importerad: 2002-03-14 00:00 av Brevbäraren
Extern mottagare: hologram <holo@brained.org>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <21407>
Kommentar till text 8132202 av hologram <holo@brained.org>
Ärende: Re: zlibscan : script to find suid binaries possibly affected by zlib vulnerability
------------------------------------------------------------
From: Florian Weimer <Weimer@CERT.Uni-Stuttgart.DE>
To: hologram <holo@brained.org>
Cc: <bugtraq@securityfocus.com>
Message-ID: <87d6y88fka.fsf@CERT.Uni-Stuttgart.DE>
hologram <holo@brained.org> writes:
> The following is a quick shell script to find suid binaries that are
> potentially affected by the zlib vulnability (i.e., those dynamically
> linked).
The hard case are statically linked binaries, though. I've written a
short Perl script which scans for signatures found in compiled zlib
code. The signatures are based on zlib's data tables, not machine
code, so they are fairly architecture-independent (modulo the 32/64
bit and endian issues addressed by the script).
--
Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
#!/usr/bin/perl -w
# find-zlib - scan for zlib tables in compiled code
# Copyright (C) 2002 RUS-CERT, University of Stuttgart.
# Written by Florian Weimer <Weimer@CERT.Uni-Stuttgart.DE>.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
# $Id: find-zlib,v 1.8 2002/03/13 18:42:44 rusfw Exp $
# <http://CERT.Uni-Stuttgart.DE/files/fw/find-zlib>
use strict;
if (@ARGV == 0 or $ARGV[0] eq '-h') {
print <<EOF;
find-zlib - scan for zlib tables in compiled code
Copyright (C) 2002 RUS-CERT, University of Stuttgart.
Usage: find-zlib [-v] filename...
In non-verbose mode (without the "-v" flag), find-zlib scans only for
three signatures:
- The "cplenx table". It is not specific to zlib, but used
by any inflate decoder.
- The "cplext table". This table is specific to zlib and
also gives some version information.
- The "inflate" copyright string.
Even if the copyright string has been removed, the other two
signatures permit the identification of zlib inflate code.
In verbose mode, additional signatures are tested:
- The "configuration table". It is specific to zlib, but not
required by the inflate code.
- Some common messages found in zlib.
- The "deflate" copyright string. Note that the deflate code is
independent of the inflate code.
Thanks to Mark Adler for helpful suggestions.
Send comments to fw-tracker\@CERT.Uni-Stuttgart.DE.
EOF
exit 1;
}
my $verbose = 0;
if ($ARGV[0] eq "-v") {
$verbose = 1;
shift @ARGV;
}
$/ = undef;
my @cplens_table = (3, 4, 5, 6, 7, 8, 9, 10, 11, 13, 15, 17, 19, 23, 27, 31,
35, 43, 51, 59, 67, 83, 99, 115, 131, 163, 195, 227,
258, 0, 0);
my @cplext_table_092 = (0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 2, 2, 2, 2,
3, 3, 3, 3, 4, 4, 4, 4, 5, 5, 5, 5, 0, 128,
128); my @cplext_table_104 = (0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 2,
2, 2, 2,
3, 3, 3, 3, 4, 4, 4, 4, 5, 5, 5, 5, 0, 192, 192);
my @cplext_table_114 = (0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 2, 2, 2, 2,
3, 3, 3, 3, 4, 4, 4, 4, 5, 5, 5, 5, 0, 112, 112);
sub table_to_re (@) {
my $be = "";
my $le = "";
my $e;
foreach $e (@_) {
$be .= pack "N", $e;
$le .= pack "V", $e;
}
return (quotemeta($be), quotemeta($le));
}
sub table_to_re_config (@) {
my $be = "";
my $le = "";
my $e;
foreach $e (@_) {
$be .= pack "n", $e;
$le .= pack "v", $e;
}
return (quotemeta($be), quotemeta($le));
}
sub table_to_re_combined (@) {
my ($be, $le) = table_to_re(@_);
return "($be|$le)";
}
my ($cplens_table_be, $cplens_table_le) = table_to_re (@cplens_table);
my ($cplext_table_092, $cplext_table_104, $cplext_table_114) =
(table_to_re_combined(@cplext_table_092),
table_to_re_combined(@cplext_table_104),
table_to_re_combined(@cplext_table_114));
my $line;
my (@config_table_le, @config_table_be) = ();
foreach $line ([8, 32, 128, 256],
[32, 128, 258, 1024],
[32, 258, 258, 4096]) {
my ($be, $le) = table_to_re_config(@$line);
push @config_table_be, $be;
push @config_table_le, $le;
}
my ($config_table_be_32,
$config_table_be_64,
$config_table_le_32,
$config_table_le_64)
= (join("....", @config_table_be),
join("........", @config_table_be),
join("....", @config_table_le),
join("........", @config_table_le));
my $file;
my $found = 1;
for $file (@ARGV) {
warn "$file: non-regular file ignored\n" unless -f $file;
unless (open(FILE, "<$file")) {
warn("$file: cannot read file\n");
next;
}
my $data = <FILE>;
close FILE;
if ($data =~/inflate ([0-9][ 0-9a-zA-Z.\-]{1,100}[0-9a-zA-Z.\-])/) {
print "$file: inflate version: \"$1\"\n";
$found = 0;
}
if ($verbose
and $data =~/deflate ([0-9][ 0-9a-zA-Z.\-]{1,100}[0-9a-zA-Z.\-])/) {
print "$file: deflate version: \"$1\"\n";
$found = 0;
}
if ($data =~ /$cplens_table_le/o) {
print "$file: zlib cplens table, little endian\n";
$found = 0;
}
if ($data =~ /$cplens_table_be/o) {
print "$file: zlib cplens table, big endian\n";
$found = 0;
}
if ($data =~ /$cplext_table_092/o) {
print "$file: zlib cplext table (version 0.1 to 0.92)\n";
$found = 0;
}
if ($data =~ /$cplext_table_104/o) {
print "$file: zlib cplext table (version 0.93 to 1.0.4)\n";
$found = 0;
}
if ($data =~ /$cplext_table_114/o) {
print "$file: zlib cplext table (version 1.0.5 to 1.1.4)\n";
$found = 0;
}
next if not $verbose;
if ($data =~ /$config_table_le_32/o) {
print "$file: zlib configuration table, little endian, 32 bit\n";
$found = 0;
}
if ($data =~ /$config_table_be_32/o) {
print "$file: zlib configuration table, big endian, 32 bit\n";
$found = 0;
}
if ($data =~ /$config_table_le_64/o) {
print "$file: zlib configuration table, little endian, 64 bit\n";
$found = 0;
}
if ($data =~ /$config_table_be_64/o) {
print "$file: zlib configuration table, big endian, 64bit\n";
$found = 0;
}
my $msg = 0;
my $total = 0;
$msg++ if $data =~ /empty distance tree with lengths/; $total++;
$msg++ if $data =~ /incomplete distance tree/; $total++;
$msg++ if $data =~ /incomplete dynamic bit lengths tree/; $total++;
$msg++ if $data =~ /incomplete literal\/length tree/; $total++;
$msg++ if $data =~ /incorrect data check/; $total++;
$msg++ if $data =~ /incorrect header check/; $total++;
$msg++ if $data =~ /invalid bit length repeat/; $total++;
$msg++ if $data =~ /invalid block type/; $total++;
$msg++ if $data =~ /invalid stored block lengths/; $total++;
$msg++ if $data =~ /invalid stored block lengths/; $total++;
$msg++ if $data =~ /invalid window size/; $total++;
$msg++ if $data =~ /need dictionary/; $total++;
$msg++ if $data =~ /oversubscribed distance tree/; $total++;
$msg++ if $data =~ /oversubscribed dynamic bit lengths tree/; $total++;
$msg++ if $data =~ /oversubscribed literal\/length tree/; $total++;
$msg++ if $data =~ /too many length or distance symbols/; $total++;
$msg++ if $data =~ /too many length or distance symbols/; $total++;
$msg++ if $data =~ /unknown compression method/; $total++;
if ($msg > 0) {
print "$file: $msg out of $total messages\n";
$found = 0;
}
}
exit $found;
(8137097) /Florian Weimer <Weimer@CERT.Uni-Stuttgart.DE>/(Ombruten)
8137194 2002-03-13 19:41 +0100 /25 rader/ Jean-loup Gailly <jloup@gzip.org>
Sänt av: joel@lysator.liu.se
Importerad: 2002-03-14 00:36 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern mottagare: vulnwatch@vulnwatch.org
Externa svar till: jloup@gzip.org
Mottagare: Bugtraq (import) <21409>
Kommentar till text 8132202 av hologram <holo@brained.org>
Ärende: Re: zlibscan : script to find suid binaries possibly affected by zlib vulnerability
------------------------------------------------------------
From: Jean-loup Gailly <jloup@gzip.org>
To: <bugtraq@securityfocus.com>, <vulnwatch@vulnwatch.org>
Message-ID: <15503.40261.515162.26435@kerla.poseidon-tech.com>
hologram writes:
> The following is a quick shell script to find suid binaries that are
> potentially affected by the zlib vulnability (i.e., those dynamically
> linked).
> #!/bin/sh
> (ldd `find /bin -perm -4000` 2> /dev/null | grep zlib) > zlib.lst
[...]
Florian Weimer <weimer@cert.uni-stuttgart.de> has written find-zlib
http://cert.uni-stuttgart.de/files/fw/find-zlib
which will do a much better job of finding applications using zlib.
A partial list of such applications is given in
http://www.gzip.org/zlib/apps.html
Thanks to Roman Drahtmueller <draht@suse.de> for contributing most of
this list.
Jean-loup
(8137194) /Jean-loup Gailly <jloup@gzip.org>/-------
8137243 2002-03-13 13:17 +0100 /37 rader/ Dimitry Andric <dim@xs4all.nl>
Sänt av: joel@lysator.liu.se
Importerad: 2002-03-14 00:48 av Brevbäraren
Extern mottagare: hologram <holo@brained.org>
Extern kopiemottagare: bugtraq@securityfocus.com
Extern kopiemottagare: vulnwatch@vulnwatch.org
Externa svar till: dim@xs4all.nl
Mottagare: Bugtraq (import) <21410>
Kommentar till text 8132202 av hologram <holo@brained.org>
Ärende: Re: zlibscan : script to find suid binaries possibly affected by zlib vulnerability
------------------------------------------------------------
From: Dimitry Andric <dim@xs4all.nl>
To: hologram <holo@brained.org>
Cc: bugtraq@securityfocus.com, vulnwatch@vulnwatch.org
Message-ID: <1859563671.20020313131721@xs4all.nl>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2002-03-12 at 03:36:35 hologram wrote:
h> The following is a quick shell script to find suid binaries that
h> are potentially affected by the zlib vulnability (i.e., those
h> dynamically linked).
==snip==
h> (ldd `find /bin -perm -4000` 2> /dev/null | grep zlib) > zlib.lst
You might want to search for "libz", because most systems use
libz.so.NN as the filename for the zlib shared libary. Also, why don't
you simply search off the root directory?
Cheers,
- --
Dimitry Andric <dim@xs4all.nl>
PGP Key: http://www.xs4all.nl/~dim/dim.asc
Fingerprint: 7AB462D2CE35FC6D42394FCDB05EA30A2E2096A3
Lbh ner abj va ivbyngvba bs gur QZPN
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5i
Comment: http://www.gn.apc.org/duncan/stoa_cover.htm
iQA/AwUBPI81SbBeowouIJajEQKPrgCglDtC+CE3y82BQdfENl6E8usfApEAn1Pz
8wpSVOudsmoUmivQHdg9zYdo
=gpjk
-----END PGP SIGNATURE-----
(8137243) /Dimitry Andric <dim@xs4all.nl>/----------
8137851 2002-03-13 11:51 +0100 /38 rader/ Guy Poizat <poizat@partsonline.fr>
Sänt av: joel@lysator.liu.se
Importerad: 2002-03-14 03:16 av Brevbäraren
Extern mottagare: holo@brained.org
Extern mottagare: bugtraq@securityfocus.com
Extern mottagare: vulnwatch@vulnwatch.org
Mottagare: Bugtraq (import) <21415>
Kommentar till text 8132202 av hologram <holo@brained.org>
Ärende: Re: zlibscan : script to find suid binaries possibly affected by zlib vulnerability
------------------------------------------------------------
From: Guy Poizat <poizat@partsonline.fr>
To: holo@brained.org, bugtraq@securityfocus.com,
vulnwatch@vulnwatch.org
Message-ID: <5.1.0.14.0.20020313114921.00a6b200@pop.partsonline.fr>
Could be worth also checking for sgid binaries using
"find -perm -4000 -or -perm -2000"
And the real paranoid would instead check for all execs.
--
Guy
At 03:36 12/03/2002, hologram wrote:
>Hi,
>
>The following is a quick shell script to find suid binaries that are
>potentially affected by the zlib vulnability (i.e., those dynamically
>linked).
>
>-[snip]-----------------------------------------------------------------
>
>#!/bin/sh
># zlibscan by hologram <holo@brained.org>
># This will scan to find suid binaries potentially affected by the zlib
># vulnerablity. These are important directories for the Linux system,
># try different ones for other systems (i.e., /usr/etc, /usr/local/bin).
>(ldd `find /bin -perm -4000` 2> /dev/null | grep zlib) > zlib.lst
>(ldd `find /sbin -perm -4000` 2> /dev/null | grep zlib) >> zlib.lst
>(ldd `find /usr/bin -perm -4000` 2> /dev/null | grep zlib) >> zlib.lst
>(ldd `find /etc -perm -4000` 2> /dev/null | grep zlib) >> zlib.lst
>(ldd `find /var -perm -4000` 2> /dev/null | grep zlib) >> zlib.lst
>
>-[snap]-----------------------------------------------------------------
>
>- hologram
(8137851) /Guy Poizat <poizat@partsonline.fr>/------
8137181 2002-03-13 14:24 +0200 /40 rader/ Bernd Jendrissek <berndj@prism.co.za>
Sänt av: joel@lysator.liu.se
Importerad: 2002-03-14 00:29 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <21408>
Ärende: Re: zlibscan : script to find suid binaries possibly affected by zlib vulnerability
------------------------------------------------------------
From: Bernd Jendrissek <berndj@prism.co.za>
To: bugtraq@securityfocus.com
Message-ID: <20020313142405.A9365@prism.co.za>
In article <Pine.BSO.4.33.0203112131260.11537-100000@brained.org> hologram <holo@brained.org> wrote:
>The following is a quick shell script to find suid binaries that are
>potentially affected by the zlib vulnability (i.e., those dynamically
>linked).
>
>-[snip]-----------------------------------------------------------------
[snip again]
I'm more concerned about *statically* linked binaries, since
dynamically linked binaries should automagically use the patched libz
when it is installed.
# find / -type f -print0 |xargs -0 strings -af |grep '\(in\|de\)flate.*\(Gailly\|Adler\)'
(Apologies to Gailly and Adler.)
Besides the usual suspects (/usr/lib/libz*, etc.) here are some binaries I
would consider "sensitive":
> /bin/rpm
> /sbin/install-info
"Never install packages from untrusted sources"
> /sbin/sash
Understandable, sa == Stand-Alone
> lots of stuff under /usr/X11R6/bin - of course
> /usr/bin/rpm2cpio
> /usr/bin/cvs
So anoncvs can "fix" gcc to become like dmr's trusting-trust C compiler?
> /usr/bin/rsync
> /usr/lib/kaffe/libawt-1.0.6.so
> some stuff under /usr/lib/perl5
> /usr/sbin/pppdump
Now all you need to do is dial up and send some bogus compressed PPP?
Unlimited ISP access? Neat!
Bernd Jendrissek
(8137181) /Bernd Jendrissek <berndj@prism.co.za>/(Ombruten)
8142976 2002-03-14 00:46 +0100 /15 rader/ tele <tele@duepi.it>
Sänt av: joel@lysator.liu.se
Importerad: 2002-03-15 00:48 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <21428>
Ärende: about zlib vulnerability
------------------------------------------------------------
From: tele <tele@duepi.it>
To: <bugtraq@securityfocus.com>
Message-ID: <20020314004010.B2283-100000@shade.bofh.net>
The vulnerable zlib 1.1.3 code can be even found on the freeswan
1.95 source tree and previous versions, therefore there's a
potential vulnerability at kernel level; besides at the web site
http://www.freeswan.org the problem is not properly treated.
regards,
--
eLv
(8142976) /tele <tele@duepi.it>/--------------------
Kommentar i text 8143064 av Paul Wouters <paul@xtdnet.nl>
Kommentar i text 8143105 av Davis Ray Sickmon, Jr <midryder@midnightryder.com>
8143064 2002-03-15 01:16 +0100 /28 rader/ Paul Wouters <paul@xtdnet.nl>
Sänt av: joel@lysator.liu.se
Importerad: 2002-03-15 01:40 av Brevbäraren
Extern mottagare: tele <tele@duepi.it>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <21429>
Kommentar till text 8142976 av tele <tele@duepi.it>
Ärende: Re: about zlib vulnerability
------------------------------------------------------------
From: Paul Wouters <paul@xtdnet.nl>
To: tele <tele@duepi.it>
Cc: <bugtraq@securityfocus.com>
Message-ID: <Pine.LNX.4.33.0203150114270.15946-100000@expansionpack.xtdnet.nl>
On Thu, 14 Mar 2002, tele wrote:
> The vulnerable zlib 1.1.3 code can be even found on the freeswan
> 1.95 source tree and previous versions, therefore there's a
> potential vulnerability at kernel level; besides at the web site
> http://www.freeswan.org the problem is not properly treated.
From the Freeswan list:
Henry Spencer <henry@spsystems.net> wrote:
> The FreeS/WAN project classes this bug as non-critical, because an IPsec
> packet must pass authentication (and be successfully decrypted) before our
> copy of zlib is asked to decompress it, even if the configuration permits
> compression (which the default ones do not). This greatly limits real
> exposure as a result of this bug.
>
> Our next release (1.97, expected at the beginning of April) will
> incorporate the fix.
Paul
(8143064) /Paul Wouters <paul@xtdnet.nl>/-----------
8146928 2002-03-14 18:47 -0800 /34 rader/ Peter Mueller <pmueller@sidestep.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-03-15 21:46 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: 'tele' <tele@duepi.it>
Mottagare: Bugtraq (import) <21444>
Ärende: RE: [Whitehat] about zlib vulnerability
------------------------------------------------------------
From: Peter Mueller <pmueller@sidestep.com>
To: bugtraq@securityfocus.com
Cc: 'tele' <tele@duepi.it>
Message-ID: <37328159548B4242A34141B1A69CDB7303270E@exchange.sidestep.com>
> The vulnerable zlib 1.1.3 code can be even found on the freeswan
> 1.95 source tree and previous versions, therefore there's a
> potential vulnerability at kernel level; besides at the web site
> http://www.freeswan.org the problem is not properly treated.
From the developers @ freeswan:
<snip>
It is not of great importance to VPN applications, since compressed
packets don't get fed to zlib until they've passed authentication. It's a
little more serious for opportunistic encryption, where the tunnel doesn't
imply trust... but our experimental OE setup currently isn't proposing or
accepting compression.
</snip>
Zlib apparently is not called into play unless the "compress=yes"
option is turned on. This feature could be individual to each tunnel
or globally set for all tunnels. default = no. Additionally in
order for zlib to even be accessed you have to authenticate an IPsec
session.
FYI, "opportunistic encryption" means using DNS to accomplish IPsec
gateways without hard-coding ipsec setup information into some
configuration file. It's currently still very experimental and thus
not used in any production environments.
Hope that helps,
Peter
(8146928) /Peter Mueller <pmueller@sidestep.com>/(Ombruten)