Bugzilla – Bug 95512
VUL-0: CVE-2005-2096: potentially more zlib memory corruption issues
Last modified: 2021-11-10 10:56:02 UTC
via vendor-sec, not public From: Mark Brown <broonie@sirena.org.uk> To: team@security.debian.org Subject: [markus@oberhumer.com: [Zlib-devel] [SECURITY] ENOUGH is probably not enough] X-Cookie: Gloffing is a state of mine. I think this is a separate issue to the one due to be released today... -- "You grabbed my hand and we fell into it, like a daydream - or a fever." From: "Markus F.X.J. Oberhumer" <markus@oberhumer.com> Organization: oberhumer.com To: zlib-devel@zlib.net X-no-Archive: yes X-Oberhumer-Conspiracy: There is no conspiracy. Trust us. Cc: Subject: [Zlib-devel] [SECURITY] ENOUGH is probably not enough X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sigma.nocdirect.com X-AntiAbuse: Original Domain - sirena.org.uk X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - madler.net X-Source: X-Source-Args: X-Source-Dir: I'm sending this in a bit of a hurry, but after looking over inftrees.c during the last days I think that the current zlib implementation has a severe problem: MAXD is wrong, so ENOUGH is probably not enough, and it may be possible to craft a special code distribution that will result in a buffer overflow in the inflate_state.codes[] array, allowing attackers to cause crashes and other denial of service scenarios (just like with the bug we have seen some days before). Please see the attached patch for a possible workaround (not tested very much, so take care). Finally please inspect the zlib-pathological-lens.gz file - _not_ the contents, but the .gz Huffman encoding. Uncompression of this file causes inflate_tables() to allocate 834 + 588 (== 1422) codes, which is already very close to the hardcoded ENOUGH (1440). Even more so because inftrees.h talks about that 850 LENS have been found... ~Markus -- Markus Oberhumer, <markus@oberhumer.com>, http://www.oberhumer.com/
Created attachment 41311 [details] zlib-fix2.patch preliminary patch to fix yet another DOS problem
From: Martin Schulze <joey@infodrom.org> This issue will be CAN-2005-1849 unless upstream has an id already. Regards, Joey
for now wait and see if final patch appears.
From: Tavis Ormandy <taviso@gentoo.org> To: Martin Schulze <joey@infodrom.org>, Free Software Distribution Vendors <vendor-sec@lst.de> Subject: Re: [vendor-sec] Re: [broonie@sirena.org.uk: [markus@oberhumer.com: [Zlib-devel] [SECURITY] ENOUGH is probably not enough]] Errors-To: vendor-sec-admin@lst.de Date: Tue, 12 Jul 2005 09:41:27 +0100 Details of this new issue from Mark Adler (please note, this issue is not public yet): > Tavis, > > FYI. > > mark > > > Begin forwarded message: >> From: Mark Adler <madler@alumni.caltech.edu> >> Date: July 11, 2005 12:59:04 AM PDT >> To: zlib-devel@zlib.net >> Cc: Subject: Re: [Zlib-devel] [SECURITY] ENOUGH is probably not enough >> Reply-To: zlib-devel@zlib.net >> >> On Jul 6, 2005, at 9:17 PM, Markus F.X.J. Oberhumer wrote: >>> Update: this is a real bug, and ENOUGH is not enough. >>> >>> I've managed to create a perfectly valid .gz file that causes >>> inflate_table() to allocate 852 + 592 (== 1444) code entries, which >>> effectively overflows inflate_state.codes[ENOUGH] by 16 bytes (ENOUGH >>> is defined as 1440). >> >> The fix is simply to change ENOUGH and MAXD. Patch below. Please >> test it along with the previous patch. I have put Markus' test file >> here: >> >> http://zlib.net/pathological-lens-20050707.gz >> >> Markus was concerned that this file should not get out, since it can >> be taken advantage of as part of an attack. So please do not send >> this link outside of this group. Also do not send the codes at the >> bottom of this email outside of this group, since that information and >> the deflate specification is all that's needed to construct an >> offending deflate stream. >> >> How the bug got there: many years ago I determined the maximum number >> of table entries required by the worst-case distance code for the >> table building code used up until zlib 1.1.4. When I rewrote the >> table builder, changing it to make it simpler, I did not recalculate >> that worst case, implicitly assuming that it had not changed. Of >> course, it had. I just did that search again today, and determined >> that Markus' 592 above is in fact the maximum. The output of the >> search is also below for the curious (only the first case requiring >> 592 table entries is shown -- there are several more). >> >> The table-building algorithm changed fundamentally, in that the new >> inflate will only make two levels of tables, no more. The old inflate >> could make three levels, which could reduce the number of table >> entries used. Hence the difference. There is no difference for >> literal/length codes, since both the old and the new inflate will only >> go to two levels of table for those. This is due to the fact that the >> requested table size is 9 bits for those codes (as opposed to 6 bits >> for distance codes), and so two levels of table are enough to get to >> the maximum code length of 15 bits. >> >> There is no point in trying to change the algorithm to use fewer table >> entries, since the additional memory required is small and since the >> new inflate table building and table use limited to two levels is >> faster. >> >> However I am thinking of making the table allocated in a later version >> of zlib (after 1.2.3). Then if the table is filled for whatever >> reason, it will be reallocated (using malloc, memcpy, and free, not >> realloc) and the process will continue. This would completely >> eliminate the concern over whether ENOUGH is really enough, and the >> table would likely never be reallocated so there would be essentially >> no execution time cost. >> >> mark >> >> >> *** ../zlib-1.2.2.3/inftrees.h Sun Aug 10 15:15:50 2003 >> --- inftrees.h Sun Jul 10 23:50:37 2005 >> *************** >> *** 1,5 **** >> /* inftrees.h -- header to use inftrees.c >> ! * Copyright (C) 1995-2003 Mark Adler >> * For conditions of distribution and use, see copyright notice in >> zlib.h >> */ >> >> --- 1,5 ---- >> /* inftrees.h -- header to use inftrees.c >> ! * Copyright (C) 1995-2005 Mark Adler >> * For conditions of distribution and use, see copyright notice in >> zlib.h >> */ >> >> *************** >> *** 36,47 **** >> */ >> >> /* Maximum size of dynamic tree. The maximum found in a long but >> non- >> ! exhaustive search was 1004 code structures (850 for >> length/literals >> ! and 154 for distances, the latter actually the result of an >> exhaustive search). The true maximum is not known, but the value >> below is more than safe. */ >> ! #define ENOUGH 1440 >> ! #define MAXD 154 >> >> /* Type of code to build for inftable() */ >> typedef enum { >> --- 36,47 ---- >> */ >> >> /* Maximum size of dynamic tree. The maximum found in a long but >> non- >> ! exhaustive search was 1444 code structures (852 for >> length/literals >> ! and 592 for distances, the latter actually the result of an >> exhaustive search). The true maximum is not known, but the value >> below is more than safe. */ >> ! #define ENOUGH 2048 >> ! #define MAXD 592 >> >> /* Type of code to build for inftable() */ >> typedef enum { >> >> >> Output of allcodes.c, showing the number of table entries used and the >> code: >> >> 2 used for: 1 1 >> generated 1 2-codes >> 4 used for: 1 2 2 >> generated 1 3-codes >> 8 used for: 1 2 3 3 >> generated 2 4-codes >> 16 used for: 1 2 3 4 4 >> generated 3 5-codes >> 32 used for: 1 2 3 4 5 5 >> generated 5 6-codes >> 64 used for: 1 2 3 4 5 6 6 >> generated 9 7-codes >> 66 used for: 1 2 3 4 5 6 7 7 >> generated 16 8-codes >> 68 used for: 1 2 3 4 5 6 7 8 8 >> generated 28 9-codes >> 72 used for: 1 2 3 4 5 6 7 8 9 9 >> generated 50 10-codes >> 80 used for: 1 2 3 4 5 6 7 8 9 10 10 >> generated 89 11-codes >> 96 used for: 1 2 3 4 5 6 7 8 9 10 11 11 >> generated 159 12-codes >> 128 used for: 1 2 3 4 5 6 7 8 9 10 11 12 12 >> generated 285 13-codes >> 192 used for: 1 2 3 4 5 6 7 8 9 10 11 12 13 13 >> generated 510 14-codes >> 320 used for: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 14 >> generated 914 15-codes >> 576 used for: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 15 >> generated 1639 16-codes >> 578 used for: 1 2 3 4 5 7 7 7 8 9 10 11 12 13 14 15 15 >> generated 2937 17-codes >> generated 5253 18-codes >> 580 used for: 1 2 3 4 5 7 8 8 8 8 8 9 10 11 12 13 14 15 15 >> generated 9329 19-codes >> 582 used for: 1 2 3 4 7 7 7 7 7 7 7 8 9 10 11 12 13 14 15 15 >> generated 16345 20-codes >> generated 28119 21-codes >> 584 used for: 1 2 3 4 7 7 7 7 7 8 8 8 8 8 9 10 11 12 13 14 15 15 >> generated 47351 22-codes >> generated 77892 23-codes >> 586 used for: 1 2 3 4 7 7 7 8 8 8 8 8 8 8 8 8 9 10 11 12 13 14 15 15 >> generated 125110 24-codes >> generated 196400 25-codes >> 588 used for: 1 2 3 4 7 7 7 7 7 8 9 9 9 9 9 9 9 9 9 10 11 12 13 14 15 >> 15 >> generated 301729 26-codes >> 590 used for: 1 2 3 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 8 9 10 11 12 13 14 >> 15 15 >> generated 454264 27-codes >> generated 671303 28-codes >> 592 used for: 1 2 3 7 7 7 7 7 7 7 7 7 7 7 7 7 8 8 8 8 8 9 10 11 12 13 >> 14 15 15 >> generated 975286 29-codes >> generated 1394743 30-codes >> 4309772 codes total >> >> Also, the first example I found for 852 entries used by literal/length >> codes is: >> 852 used for: 1 2 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 >> 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 >> 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 >> 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 >> 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 >> 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 >> 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 >> 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 >> 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 >> 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 >> 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 >> 10 10 11 11 11 11 11 12 12 12 12 12 12 12 12 12 13 13 13 13 13 13 13 >> 13 13 13 13 13 13 13 13 13 13 15 15 15 15 >> >> >> _______________________________________________ >> Zlib-devel mailing list >> Zlib-devel@madler.net >> http://madler.net/mailman/listinfo/zlib-devel_madler.net >> -- ------------------------------------- taviso@sdf.lonestar.org | finger me for my gpg key. ------------------------------------------------------- _______________________________________________ Vendor Security mailing list Vendor Security@lst.de https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
CAN-2005-1849
http://sourceforge.net/project/showfiles.php?group_id=5624&package_id=14274&release_id=343023 apparently public now
From: Mark J Cox <mjc@redhat.com> To: Marcus Meissner <meissner@suse.de> Cc: "Todd C. Miller" <Todd.Miller@courtesan.com>, Mark Hatle <mhatle@mvista.com>, vendor-sec@lst.de, Mark Adler <madler@alumni.caltech.edu> Subject: Re: [vendor-sec] Re: "ENOUGH is probably not enough" (fwd) >Yesterday apparently... To try to stop confusion we are going to describe this in the following way "A previous zlib update for CAN-2005-2096 fixed a flaw in zlib that could allow a carefully crafted compressed stream to crash an application. While the original patch corrected the reported overflow, Markus Oberhumer discovered additional ways a stream could trigger an overflow.... The Common Vulnerabilities and Exposures project (cve.mitre.org) assigned the name CAN-2005-1849 to this issue. " Cheers, Mark
Created attachment 42750 [details] pathological-lens-20050707.gz backup of referenced file.
swampid: 1857
updates released
CVE-2005-2096: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)