|Main Archive Page > Month Archives > oss-security archives|
* [2012-03-21 13:41:44 -0400] Matt Watchinski wrote:
>Yup goes somewhere useful.
>We don't have anymore information than you, but they are loaded in our
>bugtracker for investigation. From our understanding the researcher did test
>0.96.4, and not 0.97.4.
Thanks Matt, and Edwin, for the prompt responses. Hopefully the
researcher will respond as promptly (it would definitely be good to know
whether or not the current 0.97.4 is still vulnerable).
Thanks again (especially for the bugzilla links in Edwin's message).
>On Wed, Mar 21, 2012 at 12:51 PM, Vincent Danen <email@example.com> wrote:
> Hopefully security@ for ClamAV goes somewhere useful (I don't feel like
> opening a bugzilla account there just to ask this).
> Saw a bunch of CVEs come through for various anti-virus products, five
> of which are reportedly applicable for ClamAV 0.96.4. I'm wondering a)
> if the upstream folks know about these and b) whether or not the report
> has a typo in the version, since 0.97.4 is the latest upstream version?
> Indicates that CVE-2012-1419, CVE-2012-1443, CVE-2012-1457,
> CVE-2012-1458, and CVE-2012-1459 affect ClamAV 0.96.4. There isn't much
> more information though. Cutting-n-pasting from the report:
> 1. Specially crafted infected POSIX TAR files with "[aliases]" as first
> 9 bytes evades detection. (CVE-2012-1419)
> 25. Infected RAR files with initial two bytes set to 'MZ' can be fixed
> by the user and correctly extracted. Such a file evades detection.
> 39. If the length field in the header of a file with test EICAR virus
> included into a TAR archive is set to be greater than the archive's
> total length (1,000,000+original length in our experiments), the
> antivirus declares the file to be clean but virus gets extracted
> correctly by the GNU tar program. (CVE-2012-1457)
> 40. A Windows Compiled HTML Help (CHM) file is a set of HTML files,
> scripts, and images compressed using the LZX algorithm. For faster
> random accesses, the algorithm is reset at intervals instead of
> compressing the entire file as a single stream. The length of each
> interval is specified in the LZXC header.
> If an infected CHM file's header modified so that the reset interval is
> lower than in the original file, the antivirus declares the file to be
> clean. But the Windows CHM viewer hh.exe correctly decompresses the
> infected content located before the tampered header. (CVE-2012-1458)
> 41. In a POSIX TAR archive, each member file has a 512-byte header
> protected by a simple checksum. Every header also contains a file length
> field, which is used by the extractor to locate the next header in the
> If a TAR archive contains two files: the first one is clean, while the
> second is infected with test EICAR virus - and it is modified such that
> the length field in the header of the first, clean file to point into
> the middle of the header of the second, infected file. The antivirus
> declares the file to be clean but virus gets extracted correctly by the
> GNU tar program. (CVE-2012-1459)
> Vincent Danen / Red Hat Security Response Team
>V.P. Vulnerability Research (VRT)
>http://vrt-blog.snort.org && http://www.snort.org/vrt/
-- Vincent Danen / Red Hat Security Response Team