Home page logo

oss-sec logo oss-sec mailing list archives

Re: CVE request: ClamAV vulnerabilities
From: cve-assign () mitre org
Date: Wed, 11 Dec 2013 15:41:13 -0500 (EST)

Hash: SHA1

CVE for two vulnerabilities, that present in ClamAV before 0.97.7[1]:

1) A double-free error exists within the "unrar_extract_next_prepare()"
function (libclamunrar_iface/unrar_iface.c) when parsing a RAR file.

2) An unspecified error within the "wwunpack()" function
(libclamav/wwunpack.c) when unpacking a WWPack file can be exploited to
corrupt heap memory.

[1] - https://secunia.com/advisories/52647/

There are several aspects of this situation that are potentially

First, ClamAV 0.97.7 was announced on 2013-03-20 with a mention of:

  "ClamAV 0.97.7 addresses several reported potential security bugs.
   Thanks to Felix Groebert, Mateusz Jurczyk and Gynvael Coldwind of the
   Google Security Team for finding and reporting these issues."

(note that the
announcement mentions "Sorry this is late," suggesting that 0.97.7 had
been released for a while before it was announced there - the actual
release date seems to be 2013-03-14)

Separately, in


Jan Lieskovsky sent a message about "Further issue details about flaws
corrected in upstream ClamAV 0.97.7 version" and referred to commits
b2212def1bb92b5ac45c82da100dc0d1376de6a3 and
71990820d01c246e4e61408a3659dd9d92949b38. Note that this message does
not directly comment on whether those commits made it into version
0.97.7. Furthermore, one of the commits has a "cid" number. This often
means that the issue was identified by the Coverity Scan service, and
perhaps was not also identified by a human researcher.

The posted details were:

   b2212def1bb92b5ac45c82da100dc0d1376de6a3:  cid 10776 - fix double free
   71990820d01c246e4e61408a3659dd9d92949b38:  Fixed heap corruption in wwunpack.c

Then, on 2013-03-18, https://secunia.com/advisories/52647/ was
published, stating:

  Two vulnerabilities with an unknown impact have been reported in

  1) A double-free error exists within the
     "unrar_extract_next_prepare()" function
     (libclamunrar_iface/unrar_iface.c) when parsing a RAR file.

  2) An unspecified error within the "wwunpack()" function
     (libclamav/wwunpack.c) when unpacking a WWPack file can be
     exploited to corrupt heap memory.

  The vulnerabilities are reported in version 0.97.6. Prior versions
  may also be affected.

  Update to version 0.97.7.

  Provided and/or discovered by:
  The vendor credits Felix Groebert, Mateusz Jurczyk, and Gynvael
  Coldwind, Google Security Team.

Here's where it becomes potentially misleading. The first issue
apparently refers to:
  from https://github.com/vrtadmin/clamav-devel/commits/master/libclamunrar_iface/unrar_iface.c

in which a "free(comment);" line was removed. This commit did occur
before the date of the 0.97.7 release. However, anyone can download
version 0.97.7 from


and verify that this line is still present in version 0.97.7. This
would suggest that version 0.97.7 is not actually a "Solution" for
this issue. Actually, the libclamunrar_iface/unrar_iface.c file is
identical between version 0.97.6 and version 0.97.7. Also, because
this is not an issue fixed in 0.97.7, the attribution of "The vendor
credits Felix Groebert, Mateusz Jurczyk, and Gynvael Coldwind, Google
Security Team" doesn't seem to apply to this specific issue.

The second issue apparently refers to:

   from https://github.com/vrtadmin/clamav-devel/commits/master/libclamav/wwunpack.c

in which input validation was added. This commit did make it into
0.97.7 (and it's not in 0.97.6). It is also apparently discussed in
https://bugzilla.clamav.net/show_bug.cgi?id=6806 Comment 2.

Based on the http://openwall.com/lists/oss-security/2013/03/19/10
post, the other issues fixed in 0.97.7 include:

  https://bugzilla.clamav.net/show_bug.cgi?id=6809  possible buffer overflow

  For example, libclamav/yc.c in 0.97.7 has the max_emu variable that is
  apparently involved in preventing the overflow. libclamav/yc.c in 0.97.6
  does not have the max_emu variable at all.


  https://bugzilla.clamav.net/show_bug.cgi?id=6804  dbg_printhex possible information leak

  We don't know the commit for this, but libclamav/pdf.c in 0.97.6 has
  'dbg_printhex("md5", result, 32)' whereas libclamav/pdf.c in 0.97.7
  has 'dbg_printhex("md5", result, 16)' instead. We realize that the
  security impact might occur in very limited situations (e.g., the
  debug output is given to an untrusted person and the 16 extra bytes
  are somehow sensitive data). But the vendor describes it as "The
  vulnerability is merely debug-level printing" and the word
  "vulnerability" is enough for us in this context.

Some Linux distributions have already processed a subset of the above
information, e.g., see the
https://bugzilla.novell.com/show_bug.cgi?id=809945 discussion.

So, unless there are further corrections, MITRE will make three CVE

(1) 71990820d01c246e4e61408a3659dd9d92949b38
(2) e8e3746266dd3f82054ca137b81b800e54de6ebd
(3) the dbg_printhex issue with 32 instead of 16

The relevance of all this depends on the interaction between
open-source partial-disclosure approaches and the patch-backporting
mechanism. The originally questioned combination of
b2212def1bb92b5ac45c82da100dc0d1376de6a3 and
71990820d01c246e4e61408a3659dd9d92949b38 is apparently not a
complete/correct reflection of the 0.97.7 vulnerability fixes. If
someone just directly uses the upstream distribution (i.e., upgrades
from 0.97.6 to 0.97.7), then it's perhaps not critical. If something
was fixed, they get the fix. A problem would have occurred if a
distribution decided to stay with the 0.97.6 codebase (for "stability"
reasons) and only backport b2212def1bb92b5ac45c82da100dc0d1376de6a3
and 71990820d01c246e4e61408a3659dd9d92949b38. We don't know if that
happened. In a number of cases, it did not happen - the distribution
simply moved to the 0.97.7 codebase (e.g., see
and http://lists.opensuse.org/opensuse-updates/2013-03/msg00116.html).

For b2212def1bb92b5ac45c82da100dc0d1376de6a3, MITRE is generally
uncomfortable with assigning CVE IDs on the basis of someone noticing
a Coverity Scan CID number in a changelog, even if the changelog seems
to use vulnerability-style terminology such as "double free," if the
vendor isn't identifying that issue as a vulnerability. Novell/SUSE
bug 809945 (mentioned earlier) had a similar reaction in a related
context: "So far no actual security issues have been identified, just
various Coverity hardening issues were fixed." If a person would like
to produce an actual RAR file that exploits the
b2212def1bb92b5ac45c82da100dc0d1376de6a3 issue, we would of course
give you a CVE ID. Otherwise, if nothing else, adding CVE mappings
based solely on Coverity Scan CID numbers is a huge scalability issue
for us. Also, the ClamAV git apparently has several other cases where
a Coverity Scan CID number was associated with removing a "free" call,
and the others don't have CVE IDs.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
Version: GnuPG v1.4.14 (SunOS)


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]