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/
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.
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?
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.
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.
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
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
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?).
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.
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.
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.
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.
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.