|
Bugzilla – Full Text Bug Listing |
| Summary: | VUL-0: CVE-2005-2096: potentially more zlib memory corruption issues | ||
|---|---|---|---|
| Product: | [Novell Products] SUSE Security Incidents | Reporter: | Marcus Meissner <meissner> |
| Component: | Incidents | Assignee: | Marcus Meissner <meissner> |
| Status: | RESOLVED FIXED | QA Contact: | Security Team bot <security-team> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | ro, security-team |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | CVE-2005-2096: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) | ||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
zlib-fix2.patch
pathological-lens-20050707.gz |
||
|
Description
Marcus Meissner
2005-07-07 11:32:44 UTC
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) |