Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 329891 - <app-arch/cabextract-1.3: Infinite loop in MS-ZIP decoder (CVE-2010-{2800,2801})
Summary: <app-arch/cabextract-1.3: Infinite loop in MS-ZIP decoder (CVE-2010-{2800,2801})
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
URL: http://www.cabextract.org.uk/cabextra...
Whiteboard: B2 [glsa]
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-26 10:49 UTC by Samuli Suominen
Modified: 2013-12-14 22:56 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Samuli Suominen gentoo-dev 2010-07-26 10:49:31 UTC
http://www.cabextract.org.uk/cabextract-1.3.tar.gz
Comment 1 Peter Volkov (RETIRED) gentoo-dev 2010-07-30 10:20:49 UTC
cabextract 1.3 fixes several bugs in cabextract 1.2, including fixing two security bugs.

The two security bugs are as follows:

Bug 1: Infinite loop in MS-ZIP decoder

The MS-ZIP and Quantum decoders read bits in roughly the same way as the LZX decoder, however they don't have "inject two fake bytes" code.

In the situation where read() provides zero bytes, e.g. at the end of file or end of a CAB block, the LZX decoder handles this by injecting two fake bytes, then returns an error on subsequent calls. MS-ZIP and Quantum instead return zero bytes without error. However, all three decoders are written to presume they will get at least one byte. So this could lead to an infinite loop in MS-ZIP and Quantum. An infinite loop has definitely been seen in MS-ZIP - there is a while loop in inflate() of an uncompressed block (block type 0) which won't end until enough input is provided.

Partial solution: change "if (read < 0)" to "if (read <= 0)" in mszipd.c and qtmd.c.
- http://libmspack.svn.sourceforge.net/viewvc/libmspack?view=revision&revision=90

However, this breaks compatibility with a number of MS-ZIP/Quantum encoded files. A full solution would be to implement the same bit-reading system as LZX. I've done this now, merging all the bit-reading and huffman-reading code into two new files; readbits.h and readhuff.h
- http://libmspack.svn.sourceforge.net/viewvc/libmspack?view=revision&revision=95

There are several further changes made to integrate readbits.h and readhuff.h, I recommend you look at the latest version in the source repository.
- http://libmspack.svn.sourceforge.net/viewvc/libmspack/libmspack/trunk/mspack/

Bug 2: Segmentation fault in "cabextract -t"

This bug may not affect you, depending on your implementation of mspack_system->write(). It does cause a segfault in cabextract's cabx_write() in "-t" (test archive) mode.

In the Quantum decoder, when the window wrap is reached, all currently unwritten data is flushed to disk. Sometimes, less data is needed than is flushed, which makes the variable out_bytes negative.

When the main decoding loop finishes, a final call to write() is made if out_bytes is not zero. In that situation, it calls mspack_system->write() with a negative byte count, e.g. -129 bytes. You should reject this. In cabextract's "-t" mode, this is not caught, but instead converted to an unsigned integer and passed to md5_process_bytes(), which tries to read e.g. 4294967167 bytes, causing it to read beyond the end of valid process space and thus segfault.

Solution:
- Break out to the end of the decoding loop immediately if the flush would be more than needed.
   http://libmspack.svn.sourceforge.net/viewvc/libmspack/libmspack/trunk/mspack/qtmd.c?r1=114&r2=113
- Add checking of the "bytes" argument in mspack_system read() / write() implementations, just to be sure.
   http://libmspack.svn.sourceforge.net/viewvc/libmspack?view=revision&revision=118
Comment 2 Peter Volkov (RETIRED) gentoo-dev 2010-07-30 10:24:28 UTC
New version bumped. Arch teams, please, test it and stabilize.
Comment 3 Paweł Hajdan, Jr. (RETIRED) gentoo-dev 2010-07-31 03:52:20 UTC
"enhancement" is not an appropriate priority for a security bug (it was previously a request to bump). Resetting to "normal".
Comment 4 Paweł Hajdan, Jr. (RETIRED) gentoo-dev 2010-07-31 04:35:40 UTC
x86 stable
Comment 5 Markos Chandras (RETIRED) gentoo-dev 2010-07-31 14:37:09 UTC
amd64 done
Comment 6 Raúl Porcel (RETIRED) gentoo-dev 2010-07-31 16:00:30 UTC
alpha/arm/ia64/m68k/s390/sh/sparc stable
Comment 7 Jeroen Roovers gentoo-dev 2010-07-31 17:27:10 UTC
Stable for HPPA PPC.
Comment 8 Brent Baude (RETIRED) gentoo-dev 2010-08-03 17:19:04 UTC
ppc64 done
Comment 9 Stefan Behte (RETIRED) gentoo-dev Security 2010-09-03 21:49:27 UTC
CVE-2010-2800 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-2800):
  The MS-ZIP decompressor in cabextract before 1.3 allows remote
  attackers to cause a denial of service (infinite loop) via a
  malformed MSZIP archive in a .cab file during a (1) test or (2)
  extract action, related to the libmspack library.

CVE-2010-2801 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-2801):
  Integer signedness error in the Quantum decompressor in cabextract
  before 1.3, when archive test mode is used, allows user-assisted
  remote attackers to cause a denial of service (application crash) or
  possibly execute arbitrary code via a crafted Quantum archive in a
  .cab file, related to the libmspack library.

Comment 10 Tim Sammut (RETIRED) gentoo-dev 2010-09-30 20:47:46 UTC
GLSA request filed.
Comment 11 GLSAMaker/CVETool Bot gentoo-dev 2013-12-14 22:56:45 UTC
This issue was resolved and addressed in
 GLSA 201312-09 at http://security.gentoo.org/glsa/glsa-201312-09.xml
by GLSA coordinator Chris Reffett (creffett).