As said in :
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:
Target keywords : "alpha amd64 hppa ia64 ppc ppc64 sparc x86"
Stable for HPPA.
Tested on x86, looks good to go.
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
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
(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. email@example.com might be much better.
GLSA 201009-06, thanks everyone.