Bug 470783 (CVE-2008-5050) - CVE-2008-5050 clamav: get_unicode_name() off-by-one buffer overflow (< 0.94.1)
Summary: CVE-2008-5050 clamav: get_unicode_name() off-by-one buffer overflow (< 0.94.1)
Alias: CVE-2008-5050
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2008-11-10 08:54 UTC by Tomas Hoger
Modified: 2019-09-29 12:27 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-03-29 09:20:33 UTC

Attachments (Terms of Use)

Description Tomas Hoger 2008-11-10 08:54:07 UTC
Quoting report from Moritz Jodeit:

  ClamAV contains an off-by-one heap overflow vulnerability in the
  code responsible for parsing VBA project files. Successful
  exploitation could allow an attacker to execute arbitrary code with
  the privileges of the `clamd' process by sending an email with a
  prepared attachment.

  The vulnerability occurs inside the get_unicode_name() function
  in libclamav/vba_extract.c when a specific `name' buffer is passed
  to it.


Fixed upstream in: 0.94.1

Upstream bug (currently not public):

Upstream commit:
svn diff -c 4311 http://svn.clamav.net/svn/clamav-devel/

Comment 1 Robert Scheck 2008-11-10 09:15:58 UTC
Thomas, EPEL is already up2date, update should have been pushed to stable there. 
For Fedora 10, I've requested via https://fedorahosted.org/rel-eng/ticket/1014 
tagging into f10-final. Enrico seems to be AWOL and I don't want to maintain the
package, even I drove now a few updates and many for EPEL where Steve is some
kind of AWOL, too.

Do we update F-8 and F-9 also or some backporting? For both, I would like to see
some help, as I'm not using clamav on Fedora myself, just EPEL.

Comment 2 Tomas Hoger 2008-11-10 13:43:16 UTC
Well, current status of clamav in Fedora/EPEL is bit weird ;).  Enrico previously stated that he does not intend to move to new major upstream versions in stable Fedora versions, where config file format or API/ABI/soname is changed.  However, EPEL (which is expected to be bit more conservative and more likely to get backports rather than new versions) fairly closely follows upstream and rebases more frequently.  So far, Fedora got rebased to new minor versions and couple of security fixes from new major versions got backported.

As for the other distros, I think vast majority rebases often (ok, Debian does backports for stable, but has new upstream versions built for stable available in volatile and most users probably use that).  Yes, rebasing may require occasional config file tweaks on the user end, and rebuild of dependant packages on our side, but is this worse than older version which may not properly support new pattern files format and may not detect all viruses?

Comment 3 Robert Scheck 2008-11-10 17:52:14 UTC
Configuration file tweaks are optional, I never needed one. I'm running the
same clamav configuration for two years now (0.8x) and I'm only lacking some
new features, I don't enable because I'm using the old configuration and I'm
just too lazy to merge the *.rpmnew with my current one.

Anyway, if you drive e.g. a mail server with virus scanner, it is very worse
to have a more less detection rate of viruses/trojans as clamav already has;
at least what I'm seeing at work compared with proprietary scanners (~ 10%
is clamav, 90% the proprietary one). EPEL is maybe a bit more easy to handle
as there's nothing directly in it depending on the clamav-libs compared with

Finally, Enrico even doesn't touch F-8 and F-9 currently, we're AFAIK lacking
3 to 5 CVE fixes (3 or 4 CVE from 0.94, 1 CVE for 0.94.1) for both stable
Fedora releases - and AFAIK currently no backporting happened there.

Comment 4 Tomas Hoger 2008-11-13 07:47:12 UTC
CVE id CVE-2008-5050 was assigned to this issue:

Off-by-one error in the get_unicode_name function
(libclamav/vba_extract.c) in Clam Anti-Virus (ClamAV) before 0.94.1
allows remote attackers to cause a denial of service (crash) or
possibly execute arbitrary code via a crafted VBA project file, which
triggers a heap-based buffer overflow.

Comment 5 Fedora Update System 2008-11-13 18:50:09 UTC
clamav-0.93.3-2.fc9 has been submitted as an update for Fedora 9.

Comment 6 Fedora Update System 2008-11-13 18:50:15 UTC
clamav-0.92.1-4.fc8 has been submitted as an update for Fedora 8.

Comment 7 Tomas Hoger 2008-11-14 08:02:09 UTC
I submitted updates with backports yesterday, though I still believe rebasing should be considered as default approach, as it's probably time better spent.

I have another question.  Advisories for clamav issue frequently mention that "upstream has disabled affected feature 'foo' via freshclam updates".  Can anyone more familiar with clamav explain how that works or point me at some docs I failed to find?  I'm curious how this disabling and also re-enabling works (i.e. is that disablement done on version-basis?  does the feature get re-enabled for all clamav users after fixed upstream version is released?).

Comment 8 Enrico Scholz 2008-11-14 11:54:27 UTC
thanks for backporting it; but I am still against rebasing as configuration between versions is incompatible.

Some functionality can and will be disabled by normal database updates; e.g. the 'daily.cld' database contains 


entries which tell version numbers/functionality levels for which certain modules are deactivated. Former clamav version used a separate file for these information.

These entries are transmitted as soon as a security bug was reported.

Comment 9 Fedora Update System 2008-11-14 12:44:45 UTC
clamav-0.93.3-2.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 10 Fedora Update System 2008-11-14 12:46:20 UTC
clamav-0.92.1-4.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 11 Tomas Hoger 2008-11-14 12:52:59 UTC
Can you please translate that example to more human readable format?  Does that
mean that feature specified as first item (DOCUMENT, ARCHIVE, PE) is disabled
in between versions specified by 3rd and 4th argument?  If so, your example
suggests that such restrictions are not removed when fixed upstream version is
made available.  If that is the case, does it make any sense to backport fixes?
 Those backports do not bump functionality levels (I don't think they should),
so when we're staying at the older version, we do not really need the patches
(affected module is disabled via database updates), but in the time, more and
more clamav capabilities get disabled as various vulnerabilities are

As for config changes, I think it's also about users' expectation.  If users
are able to understand that they need to fix their config from time to time to
take advantage of all clamav features, they likely will understand.

Comment 12 Enrico Scholz 2008-12-03 14:19:18 UTC
Your interpretation of the field entries is correct.  Backported changes will protect vanilla installations (which never ran a database update) but the modules will are still disabled.

Nevertheless, updates to a new major version are a no-go when existing configuration becomes invalid. Especially for a component like 'clamav' which might be used at mailservers. Broken configuration can cause rejected mails there.

As some functionality (RAR) is already disabled, most users will probably rebuild 'clamav' (with an '--with unrar' option) from devel branch.

Note You need to log in before you can comment on or make changes to this bug.