Bug 470783 - (CVE-2008-5050) CVE-2008-5050 clamav: get_unicode_name() off-by-one buffer overflow (< 0.94.1)
CVE-2008-5050 clamav: get_unicode_name() off-by-one buffer overflow (< 0.94.1)
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
cwe=CWE-193->CWE-122
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-10 03:54 EST by Tomas Hoger
Modified: 2016-01-27 10:46 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-29 05:20:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Tomas Hoger 2008-11-10 03:54:07 EST
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.

Reference:
http://marc.info/?l=bugtraq&m=122624716807236&w=4

Fixed upstream in: 0.94.1

Upstream bug (currently not public):
https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1239

Upstream commit:
http://svn.clamav.net/websvn/diff.php?repname=clamav-devel&path=/trunk/libclamav/vba_extract.c&rev=4311
svn diff -c 4311 http://svn.clamav.net/svn/clamav-devel/
Comment 1 Robert Scheck 2008-11-10 04:15:58 EST
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 08:43:16 EST
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 12:52:14 EST
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
Fedora.

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 02:47:12 EST
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 13:50:09 EST
clamav-0.93.3-2.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/clamav-0.93.3-2.fc9
Comment 6 Fedora Update System 2008-11-13 13:50:15 EST
clamav-0.92.1-4.fc8 has been submitted as an update for Fedora 8.
http://admin.fedoraproject.org/updates/clamav-0.92.1-4.fc8
Comment 7 Tomas Hoger 2008-11-14 03:02:09 EST
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 06:54:27 EST
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 

DOCUMENT:0x3:14:15                                                                                                                                                                                               
ARCHIVE:0x79f:13:14                                                                                                                                                                                              
PE:0xb4ff:13:23                                                                                                                                                                                                  
PE:0x94ff:24:25                                                                                                                                                                                                  
PE:0xb4ff:26:28                                                                                                                                                                                                  
...

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 07:44:45 EST
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 07:46:20 EST
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 07:52:59 EST
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
discovered.

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 09:19:18 EST
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.