Bug 314087 – <app-antivirus/clamav-0.96: Scanning Bypass and Memory Corruption (CVE-2010-{0098,1311})

• Status: RESOLVED FIXED
• Product: Gentoo Security

[Description Tomás Touceda (RETIRED) 2010-04-09 11:33:06 UTC]

As said in [0]:

A weakness and a vulnerability have been reported in ClamAV, which can be exploited by malicious people to bypass the scanning functionality or potentially compromise a vulnerable system.

1) An error when processing archives can be exploited to bypass the anti-virus scanning functionality via specially crafted CAB files.

2) An error exists within the "qtm_decompress()" function in libclamav/mspack.c. This can be exploited to cause a memory corruption when a specially crafted Quantum-compressed file is scanned.

Successful exploitation of this vulnerability may allow execution of arbitrary code.

The weakness and the vulnerability are reported in versions prior to 0.96.
------------------------------

Arches, please test and mark stable:
=app-antivirus/clamav-0.96
Target keywords : "alpha amd64 hppa ia64 ppc ppc64 sparc x86"

[0] http://secunia.com/advisories/39329/

[Comment 1 Jeroen Roovers (RETIRED) 2010-04-10 15:08:52 UTC]

Stable for HPPA.

[Comment 2 Andreas Schürch 2010-04-10 18:59:52 UTC]

Tested on x86, looks good to go.

[Comment 3 Stefan Behte (RETIRED) 2010-04-11 14:02:58 UTC]

CVE-2010-0098 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-0098):
  ClamAV before 0.96 does not properly handle the (1) CAB and (2) 7z
  file formats, which allows remote attackers to bypass virus detection
  via a crafted archive that is compatible with standard archive
  utilities.

CVE-2010-1311 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-1311):
  The qtm_decompress function in libclamav/mspack.c in ClamAV before
  0.96 allows remote attackers to cause a denial of service (memory
  corruption and application crash) via a crafted CAB archive that uses
  the Quantum (aka .Q) compression format.  NOTE: some of these details
  are obtained from third party information.

[Comment 4 Christian Faulhammer (RETIRED) 2010-04-12 13:12:29 UTC]

stable x86, thanks Andreas

[Comment 5 Brent Baude (RETIRED) 2010-04-12 18:48:44 UTC]

ppc64 done

[Comment 6 Brent Baude (RETIRED) 2010-04-12 20:50:53 UTC]

ppc done

[Comment 7 Raúl Porcel (RETIRED) 2010-04-16 18:29:59 UTC]

alpha/ia64/sparc stable

[Comment 8 Tobias Scherbaum (RETIRED) 2010-04-16 18:37:44 UTC]

(In reply to comment #7)
> alpha/ia64/sparc stable
> 

... and re-open this bug.

[Comment 9 Markus Meier 2010-04-17 22:22:27 UTC]

amd64 stable, all arches done.

[Comment 10 Stefan Behte (RETIRED) 2010-05-22 11:19:45 UTC]

glsa request filed

[Comment 11 Laszlo Valko 2010-05-26 21:33:36 UTC]

Guys, I may be missing the point or I may not complain at the right place, but since the 3rd of March 2010, I have not seen a single GLSA released for any vulnerabilities. Now it could be possible that there was no reason to produce one, but I seriously doubt that.

[Comment 12 Tobias Scherbaum (RETIRED) 2010-05-27 05:29:43 UTC]

(In reply to comment #11)
> Guys, I may be missing the point or I may not complain at the right place, but
> since the 3rd of March 2010, I have not seen a single GLSA released for any
> vulnerabilities. Now it could be possible that there was no reason to produce
> one, but I seriously doubt that.
> 

and still: this is the wrong place to discuss issues like that. [e-mail] might be much better.

[Comment 13 Stefan Behte (RETIRED) 2010-09-29 20:54:41 UTC]

GLSA 201009-06, thanks everyone.