Summary: | <app-antivirus/clamav-0.96: Scanning Bypass and Memory Corruption (CVE-2010-{0098,1311}) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Tomás Touceda (RETIRED) <chiiph> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | antivirus, gentoo.bugs |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1826 | ||
Whiteboard: | B2 [glsa] | ||
Package list: | Runtime testing required: | --- |
Description
Tomás Touceda (RETIRED)
2010-04-09 11:33:06 UTC
Stable for HPPA. Tested on x86, looks good to go. 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. stable x86, thanks Andreas ppc64 done ppc done alpha/ia64/sparc stable (In reply to comment #7) > alpha/ia64/sparc stable > ... and re-open this bug. amd64 stable, all arches done. glsa request filed 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. (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. gentoo-dev@gentoo.org might be much better. GLSA 201009-06, thanks everyone. |