Посылаю данные из первоисточников для реальной оценки опасности уязвимости
1)
Tavis Ormandy of the Google Security Team discovered two denial of service
flaws in the way gzip expanded archive files. If a victim expanded a
specially crafted archive, it could cause the gzip executable to hang or
crash. (CVE-2006-4334, CVE-2006-4338)
Tavis Ormandy of the Google Security Team discovered several code execution
flaws in the way gzip expanded archive files. If a victim expanded a
specially crafted archive, it could cause the gzip executable to crash or
execute arbitrary code. (CVE-2006-4335, CVE-2006-4336, CVE-2006-4337)
2)
Tavis Ormandy of the Google Security Team discovered several vulnerabilities in
gzip. The important bits of his mail are below:
--------------------------------------------------------------------------
* NULL Dereference (gzip-huftbuild-NULL-deref.gz)
CVE-2006-4334
--------------------------------------------------------------------------
* OOB Write (gzip-lzh-stack-modify.Z)
CVE-2006-4335
A stack modification vulnerability (where a stack buffer can be
modified out of bounds, but not in the traditional stack overrun
sense) exists in the LZH decompression support, The following loop
from make_table() (~139, unlzh.c) assumes that no entry in bitlen[]
can exceed 16:
for (i = 0; i < nchar; i++) count[bitlen[i]]++;
This is not the case, bitlen[] can be populated with higher values by
read_pt_len(), thus incrementing values outside the bounds of the
stack buffer count[]. A datastream consisting entirely of huffman
codes with set bits demonstrates this, for example:
$ perl -e 'print "\x1f\xa0","\xab\xcd","\xff"x"2048"' | gzip -d
Please note, this may or may not cause odd behaviour, a debugger
should be used to find out if you are affected (this does not appear
to be detected by valgrind).
This vulnerability may or may not be exploitable, different behaviour
has been observed on different systems. On some systems, several saved
registers are within reach, thus allowing them to be incremented by a
significant amount (count[] is of type unsigned short[], allowing you
to manipulate the 2 MSB and LSB of a saved dword register
independently). This may be enough to move a stack frame into an
attacker controlled area, adjust the return address, or should a
register jump be performed on a saved register (eg, ljmp ebx), then an
attacker may be able to move the destination to another controlled
area.
If no stack data can be reached, the impact of this vulnerability is
low. This can be found in gdb as follows:
$ gdb -q gzip
(gdb) b make_table
Breakpoint 1 at 0x804f246: file unlzh.c, line 146.
(gdb) r --decompress < testcase.Z
Breakpoint 1, make_table (nchar=19, bitlen=0x80551c4 "\024\024\024",
tablebits=8, table=0x8054fc0) at unlzh.c:146
(gdb) info frame
Stack level 0, frame at 0xffffd5d4:
eip = 0x804f246 in make_table (unlzh.c:146); saved eip 0x804f589
called by frame at 0xffffd5f4
source language c.
Arglist at 0xffffd5cc, args: nchar=19, bitlen=0x80551c4
"\024\024\024", tablebits=8, table=0x8054fc0
Locals at 0xffffd5cc, Previous frame's sp is 0xffffd5d4
Saved registers:
ebx at 0xffffd5c0, ebp at 0xffffd5cc, esi at 0xffffd5c4, edi at
0xffffd5c8, eip at 0xffffd5d0
(gdb) p/x &count[21]
$1 = 0xffffd5c8
In this case, the saved ebx, esi and edi are clearly attacker controllable.
--------------------------------------------------------------------------
* Buffer underflow (gzip_pack_underflow.c, gzip-pack-underflow.z)
CVE-2006-4336
A .bss buffer underflow exists in gzip's pack support, where the
following loop from build_tree() (unpack.c, ~146) does not enforce any
lower bound while constructing the prefix table:
while (prefixes--) *--prefixp = (uch)len;
The simplified process of constructing a prefix table is as follows:
* Read the maximum length of a huffman code used in this archive.
* Ensure the maximum length is between zero and 25.
* Read the number of leaves at each code length from the archive.
* Check the sum of leaves does not exceed 256.
* For each leaf count between code lengths 1 .. min(max_code_length, 12)
initialise the prefix table to the code length.
The prefix table could theoretically contain 1<<12 entries safely,
however a leaf count table could be constructed in such a way as to
write to index (1<<12 - (0xff << (12 - 1))), or -518144 (this is the
furthest index directly reachable), thus underflowing the buffer
considerably.
* The values written to the underflowed area are attacker controlled,
but can only be within the range 0x01 to 0x0c.
* The distance from the buffer is affected by the value of the char requested,
the formula for the furthest index reachable by character value n is something
like (4096 - (0xff << 12 - n)).
* The overwrite operation can only occur once, however the condition can be
be easily modified via the first overwrite, and thus repeated multiple times.
Overwriting a buffer with multiple values is possible by building up a
new value using multiple overlapping writes.
On big endian systems, this vulnerability should be trivially
exploitable. However exploitation on intel appears to be considerably
more difficult, the most likely attack vector appears to be modifying
max_len, peek_bits, eob (indirectly) and lit_base in such a way as to
trigger an write of arbitrary data via put_ubyte() and window[], this
can then be used to modify the `work` function pointer or a .got entry
(such as free(), which is called on error) to point at an attacker
controlled buffer such as inbuf.
Alternative attack vectors may include modifying ifd, ofd, infinite loops, etc.
Please note, that on systems that compile gzip with `DYN_ALLOC`
defined, the buffer underflowed is a heap buffer. I have not
investigated this configuration in any detail.
The file gzip_pack_underflow.c attached to this mail can be used to
generate archives that demonstrate this vulnerability.
--------------------------------------------------------------------------
* Buffer overflow (gzip-lzh-bss-overflow.Z)
CVE-2006-4337
A .bss buffer overflow vulnerability exists in gzip's LZH support, due
to it's inability to handle exceptional input in the make_table()
function, a pathological decoding table can be constructed in such a
way as to generate counts so high that the rapid growth of `nextcode`
exceeds the size of the table[] buffer.
The decoding table construction code is considerably more complex than
that of pack's.
To exploit this vulnerability, an attacker would need to:
* Construct a pt_len[] such that pt_len[n] is 0.
* Construct a pt_table[] such that pt_table[(code buffer) >> 16 - 8]
is n (where n>2)
* Now c_len[] is filled with (n-2), generating exceptionally high values in
count[n-2].
The most likely targets for triggering the exploitation of arbitrary
code would be inptr, insize and inbuf, all of which are fully
controllable, and triggering a buffer refill operation with these
modified variables.
A datatream that demonstrates a pathological c_len[] can be generated
as follows:
$ perl -e 'print
"\x1f\xa0","\xab\xcd","\xf6\x40\x01\xc2\xcc\x36\x0c\x92\x00\x00\x00\x00","\xc8","\x00"x"2048"'
| gzip -d
Where the third string contains codes to populate pt_len[], which in
turn is used to generate the c_len[] in read_c_len().
Please note, this may not crash, you should use a debugger to identify
if an overflow has occurred (valgrind doesnt detect this either). If
you compile with -funit-at-a-time, you can put a watchpoint on
`foreground`, making this easier to debug, which is what I did while
testing this. eg,
$ gdb -q ./gzip
(gdb) thb unlzh
Breakpoint 1 at 0x804fe49: file unlzh.c, line 425.
(gdb) r --decompress < testcase.gz
unlzh (in=0, out=1) at unlzh.c:425
(gdb) p/x foreground
$1 = 0x1
(gdb) watch foreground != 1
Hardware watchpoint 2: foreground != 1
(gdb) c
Hardware watchpoint 2: foreground != 1
Old value = 0
New value = 1
0x0804fb49 in make_table (nchar=510, bitlen=0x80916e0 '\005' <repeats
200 times>..., tablebits=12, table=0x8060e00) at unlzh.c:214
(gdb) p/x foreground
$2 = 0x100
clearly foreground has been damaged here.
(gdb) info symbol &table[i]
foreground in section .bss
oops, table[i] has reached outside d_buf.
The public domain source on which unlzh.c is based on appears to be
used in multiple other decompressors, I have not investigated if these
are vulnerable to the same attack.
--------------------------------------------------------------------------
* Infinite loop (gzip-lzh-infinite-loop.Z)
CVE-2006-4338
The following code sequence is used in multiple locations within
unlzh.c for traversing the branches of a tree structure:
do {
if (bitbuf & mask) j = right[j];
else j = left [j];
mask >>= 1;
} while (j >= NC);
In this case, if mask is 0 and j == left[j], then the loop will
continue forever, perhaps disrupting the operation of any automated
systems relying on gzip for data decompression. The impact of this
vulnerability is obviously a minor DoS. It does not appear to be
possible to construct a tree such that (for example) left[1] == 2,
left[2] == 1 and so on. Therefore, detecting this loop is relatively
easy, adding the condition `&& (mask || j != left[j])` should be
adequate.
> -----Original Message-----
> From: 3APA3A [mailto:3APA3A@xxxxxxxxxxxxxxxx]
> Sent: Tuesday, September 19, 2006 9:58 PM
> To: security-alerts@xxxxxxxxxxxxxx
> Subject: [security-alerts] Fwd: FreeBSD Security Advisory
> FreeBSD-SA-06:21.gzip
>
>
> А вот это, если оно в библиотеке, то очень серьезно.
> Потому как даже
> Microsoft использует стандартную библиотеку gzip (к
> Internet Explorer
> одно время даже GPL прилагался :)
>
> --This is a forwarded message
> From: FreeBSD Security Advisories <security-advisories@xxxxxxxxxxx>
> To: Bugtraq <bugtraq@xxxxxxxxxxxxxxxxx>
> Date: Tuesday, September 19, 2006, 6:32:48 PM
> Subject: FreeBSD Security Advisory FreeBSD-SA-06:21.gzip
>
> ===8<==============Original message text===============
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> ==============================================================
> ===============
> FreeBSD-SA-06:21.gzip
> Security Advisory
> The
> FreeBSD Project
>
> Topic: Multiple vulnerabilities in gzip
>
> Category: contrib
> Module: gzip
> Announced: 2006-09-19
> Credits: Tavis Ormandy, Google Security Team
> Affects: All FreeBSD releases.
> Corrected: 2006-09-19 14:02:30 UTC (RELENG_6, 6.2-PRERELEASE)
> 2006-09-19 14:03:26 UTC (RELENG_6_1, 6.1-RELEASE-p7)
> 2006-09-19 14:04:13 UTC (RELENG_6_0, 6.0-RELEASE-p12)
> 2006-09-19 14:06:21 UTC (RELENG_5, 5.5-STABLE)
> 2006-09-19 14:07:13 UTC (RELENG_5_5, 5.5-RELEASE-p5)
> 2006-09-19 14:08:10 UTC (RELENG_5_4, 5.4-RELEASE-p19)
> 2006-09-19 14:09:09 UTC (RELENG_5_3, 5.3-RELEASE-p34)
> 2006-09-19 14:11:35 UTC (RELENG_4, 4.11-STABLE)
> 2006-09-19 14:13:53 UTC (RELENG_4_11,
> 4.11-RELEASE-p22)
> CVE Name: CVE-2006-4334, CVE-2006-4335, CVE-2006-4336,
> CVE-2006-4337,
> CVE-2006-4338
>
> For general information regarding FreeBSD Security Advisories,
> including descriptions of the fields above, security branches, and the
> following sections, please visit <URL:>.
>
> I. Background
>
> gzip is a file compression utility.
>
> II. Problem Description
>
> Multiple programming errors have been found in gzip which can be
> triggered when gzip is decompressing files. These errors include
> insufficient bounds checks in buffer use, a NULL pointer dereference,
> and a potential infinite loop.
>
> III. Impact
>
> The insufficient bounds checks in buffer use can cause gzip to crash,
> and may permit the execution of arbitrary code. The NULL pointer
> deference can cause gzip to crash. The infinite loop can cause a
> Denial-of-Service situation where gzip uses all available CPU time.
>
> IV. Workaround
>
> No workaround is available.
>
> V. Solution
>
> Perform one of the following:
>
> 1) Upgrade your vulnerable system to 4-STABLE, 5-STABLE, or 6-STABLE,
> or to the RELENG_6_1, RELENG_6_0, RELENG_5_5, RELENG_5_4, RELENG_5_3,
> or RELENG_4_11 security branch dated after the correction date.
>
> 2) To patch your present system:
>
> The following patches have been verified to apply to FreeBSD
> 4.11, 5.3,
> 5.4, 5.5, 6.0, and 6.1 systems.
>
> a) Download the relevant patch from the location below, and verify the
> detached PGP signature using your PGP utility.
>
> # fetch
> # fetch
>
> b) Execute the following commands as root:
>
> # cd /usr/src
> # patch < /path/to/patch
> # cd /usr/src/gnu/usr.bin/gzip
> # make obj && make depend && make && make install
>
> VI. Correction details
>
> The following list contains the revision numbers of each file that was
> corrected in FreeBSD.
>
> Branch
> Revision
> Path
> -
> --------------------------------------------------------------
> -----------
> RELENG_4
> src/gnu/usr.bin/gzip/gzip.h
> 1.3.12.1
> src/gnu/usr.bin/gzip/inflate.c
> 1.8.2.2
> src/gnu/usr.bin/gzip/unlzh.c
> 1.5.2.1
> src/gnu/usr.bin/gzip/unpack.c
> 1.6.2.1
> RELENG_4_11
> src/UPDATING
> 1.73.2.91.2.23
> src/sys/conf/newvers.sh
> 1.44.2.39.2.26
> src/gnu/usr.bin/gzip/gzip.h
> 1.3.36.1
> src/gnu/usr.bin/gzip/inflate.c
> 1.8.2.1.2.1
> src/gnu/usr.bin/gzip/unlzh.c
> 1.5.30.1
> src/gnu/usr.bin/gzip/unpack.c
> 1.6.30.1
> RELENG_5
> src/gnu/usr.bin/gzip/gzip.h
> 1.4.2.1
> src/gnu/usr.bin/gzip/inflate.c
> 1.9.2.1
> src/gnu/usr.bin/gzip/unlzh.c
> 1.5.26.1
> src/gnu/usr.bin/gzip/unpack.c
> 1.6.26.1
> RELENG_5_5
> src/UPDATING
> 1.342.2.35.2.5
> src/sys/conf/newvers.sh
> 1.62.2.21.2.7
> src/gnu/usr.bin/gzip/gzip.h
> 1.4.14.1
> src/gnu/usr.bin/gzip/inflate.c
> 1.9.14.1
> src/gnu/usr.bin/gzip/unlzh.c
> 1.5.40.1
> src/gnu/usr.bin/gzip/unpack.c
> 1.6.40.1
> RELENG_5_4
> src/UPDATING
> 1.342.2.24.2.28
> src/sys/conf/newvers.sh
> 1.62.2.18.2.24
> src/gnu/usr.bin/gzip/gzip.h
> 1.4.6.1
> src/gnu/usr.bin/gzip/inflate.c
> 1.9.6.1
> src/gnu/usr.bin/gzip/unlzh.c
> 1.5.32.1
> src/gnu/usr.bin/gzip/unpack.c
> 1.6.32.1
> RELENG_5_3
> src/UPDATING
> 1.342.2.13.2.37
> src/sys/conf/newvers.sh
> 1.62.2.15.2.39
> src/gnu/usr.bin/gzip/gzip.h
> 1.4.4.1
> src/gnu/usr.bin/gzip/inflate.c
> 1.9.4.1
> src/gnu/usr.bin/gzip/unlzh.c
> 1.5.28.1
> src/gnu/usr.bin/gzip/unpack.c
> 1.6.28.1
> RELENG_6
> src/gnu/usr.bin/gzip/gzip.h
> 1.4.8.1
> src/gnu/usr.bin/gzip/inflate.c
> 1.9.8.1
> src/gnu/usr.bin/gzip/unlzh.c
> 1.5.34.1
> src/gnu/usr.bin/gzip/unpack.c
> 1.6.34.1
> RELENG_6_1
> src/UPDATING
> 1.416.2.22.2.9
> src/sys/conf/newvers.sh
> 1.69.2.11.2.9
> src/gnu/usr.bin/gzip/gzip.h
> 1.4.12.1
> src/gnu/usr.bin/gzip/inflate.c
> 1.9.12.1
> src/gnu/usr.bin/gzip/unlzh.c
> 1.5.38.1
> src/gnu/usr.bin/gzip/unpack.c
> 1.6.38.1
> RELENG_6_0
> src/UPDATING
> 1.416.2.3.2.17
> src/sys/conf/newvers.sh
> 1.69.2.8.2.13
> src/gnu/usr.bin/gzip/gzip.h
> 1.4.10.1
> src/gnu/usr.bin/gzip/inflate.c
> 1.9.10.1
> src/gnu/usr.bin/gzip/unlzh.c
> 1.5.36.1
> src/gnu/usr.bin/gzip/unpack.c
> 1.6.36.1
> -
> --------------------------------------------------------------
> -----------
>
> VII. References
>
>
>
>
>
>
>
> The latest revision of this advisory is available at
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (FreeBSD)
>
> iD8DBQFFD/6bFdaIBMps37IRAgMGAJ9f7rYLs32ZEAKWwhcPqAWrp6fNwACgg2Wj
> fw3izMEcpupfqNkkQKizV5g=
> =xYxa
> -----END PGP SIGNATURE-----
>
> ===8<===========End of original message text===========
>
>
> --
> ~/ZARAZA
> Впрочем, важнее всего - алгоритм! (Лем)
>
>
>
