Two vulnerabilities have been reported in ClamAV, which can be exploited by malicious people to cause a DoS (Denial of Service).
1) Input passed via the "id" parameter when parsing MIME headers is not properly sanitised before being used to create local files. This can be exploited to e.g. overwrite the anti-virus signature file via directory traversal attacks, preventing malware from being detected.
2) An file descriptor leak error in the processing of CAB files can be exploited to e.g. prevent legitimate users from sending out valid archives via a specially crafted CAB file with a cabinet header containing a record length of zero.
The vulnerabilities are reported in versions prior to 0.90.
Update to version 0.90.
Already in the tree... probably just need to CC arches, but I'm not sure if I should do that? Or if it needs to be looked at by a developer first...
Reproducible: Didn't try
Cc maintainers, sorry
As OP stated, the ebuild is already in the tree.
hi arches, please can you test and mark stable clamav-0.90 is appropriate, thanks
0.90 depends on sys-fs/dazuko which isn't stable on any arch - is dazuko ready for stabling?
doesn't seem to work on ppc64:
# modprobe dazuko
WARNING: Error inserting commoncap (/lib/modules/184.108.40.206/kernel/security/commoncap.ko): Invalid module format
FATAL: Error inserting dazuko (/lib/modules/220.127.116.11/misc/dazuko.ko): Invalid argument
Feb 18 14:39:46 G5 dazuko: info: using chroot events for chroot'd processes
Feb 18 14:39:46 G5 dazuko: failed to register
anyone else having this problem? or is my configuration?
(In reply to comment #6)
> doesn't seem to work on ppc64:
> # modprobe dazuko
> WARNING: Error inserting commoncap
> (/lib/modules/18.104.22.168/kernel/security/commoncap.ko): Invalid module format
> FATAL: Error inserting dazuko (/lib/modules/22.214.171.124/misc/dazuko.ko): Invalid
Can you please try modprobe commoncap (CONFIG_SECURITY_CAPABILITIES)?
This is part of kernel and should work... :(
> Feb 18 14:39:46 G5 dazuko: info: using chroot events for chroot'd processes
> Feb 18 14:39:46 G5 dazuko: failed to register
Well this is expected... Let's first try to solve commoncap...
(In reply to comment #5)
> 0.90 depends on sys-fs/dazuko which isn't stable on any arch - is dazuko ready
> for stabling?
I regret to say this... But no.
Upstream rewrote the interface for the kernel, and it has no stable release for 2.6.20...
So let's drop the onaccess USE flag until I test the new interface.
Ok, 0.90 has onaccess support dropped completely.
(I thought about just masking the use flag globally, but that would only tempt users into trying something that doesn't work.)
app-antivirus/clamav-0.90 USE="bzip2 crypt curl gmp logrotate mailwrapper -milter -onaccess (-selinux)"
1. emerges on x86 (not resynced yet)
2. passes collision test
Portage 2.1.2-r9 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.5-r0, 126.96.36.199 i686)
System uname: 188.8.131.52 i686 AMD Athlon(TM) XP1800+
Gentoo Base System release 1.12.9
Timestamp of tree: Sat, 17 Feb 2007 09:30:01 +0000
ccache version 2.4 [enabled]
dev-java/java-config: 1.3.7, 2.0.31
dev-lang/python: 2.3.5-r3, 2.4.3-r4
sys-devel/autoconf: 2.13, 2.61
sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
CFLAGS="-O2 -march=i686 -fomit-frame-pointer -pipe"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c"
CXXFLAGS="-O2 -march=i686 -fomit-frame-pointer -pipe"
FEATURES="autoconfig ccache collision-protect distlocks fixpackages metadata-transfer parallel-fetch sandbox sfperms strict test userfetch userpriv usersandbox"
LINGUAS="en de en_GB"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
USE="3dnow 3dnowext X a52 aac alsa apache2 berkdb bitmap-fonts bzip2 cairo cdr cli cracklib crypt cups dbus divx4linux dlloader dri dts dvd dvdr dvdread eds emboss exif fam ffmpeg firefox fortran gdbm gif gnome gphoto2 gpm gstreamer gtk hal iconv ipv6 isdnlog java jpeg kde ldap libg++ mad midi mikmod mmx mmxext mono mp3 mpeg ncurses network nls nptl nptlonly ogg opengl oss pam pcre perl png ppds pppd python qt qt3 qt4 quicktime readline reflection samba sdl seamonkey session spell spl ssl svg tcpd test tetex tiff truetype truetype-fonts type1-fonts unicode usb vcd vorbis win32codecs x86 xine xinerama xml xorg xprint xv xvid zlib" ELIBC="glibc" INPUT_DEVICES="mouse keyboard" KERNEL="linux" LINGUAS="en de en_GB" USERLAND="GNU" VIDEO_CARDS="nv none"
Unset: CTARGET, INSTALL_MASK, LC_ALL, LDFLAGS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS
There is a discussion on upstream ML about changed API. At least squidclamav, Mail::ClamAV perl module and havp antivirus engine are reported to NOT build with clamav-0.90.
I'll be fixing dependencies for these three and notifying their maintainers via e-mail.
(In reply to comment #13)
> I'll be fixing dependencies for these three and notifying their maintainers via
This will of course mean that these packages will depend on vulnerable clamav. Security, is this acceptable for you? I guess not...
Stable for HPPA.
Stable on amd64.
(In reply to comment #14)
> (In reply to comment #13)
> > I'll be fixing dependencies for these three and notifying their maintainers via
> > e-mail.
> This will of course mean that these packages will depend on vulnerable clamav.
> Security, is this acceptable for you? I guess not...
An answer here, perhaps? Basically, we have two options:
- packages built against an insecure libclamav (0.88.7)
- packages not compiling because of incompatible API changes in 0.90
having something insecure in the tree is not an option. any idea how hard it would be to backport patches?
(In reply to comment #20)
> having something insecure in the tree is not an option. any idea how hard it
> would be to backport patches?
The MIME vulnerability (CVE-2007-0898) fix is a one-line patch. The CAB one (CVE-2007-0897) I'm not quite sure about. Debian guys seem to have "fixed" it by commenting out CAB entry from array of known executables, which I don't think is a good idea.
I'll look into it some more.
The CAB decompressor code has been reworked completely between 0.88.7 and 0.90, and the fix for this vulnerability has been made just three hours before tagging 0.90 release in upstream's svn repo.
No trivial backport can be made here...
I have added a patch to fix most glaring API change. There are at least two more. One is non-trivial to patch in.
The other one is a removal of a function which has been marked as deprecated long time ago, so it's up to people using it to update their code.
Sorry for the delay, I had to put my head around the clamav code. :)
Marked x86 stable, yay!
Thanks Andrej, it seems all right now!
I sure vote for a GLSA and i have already file the GLSA request
yes++. lets have a glsa
GLSA 200703-03, thanks everybody
*** Bug 170711 has been marked as a duplicate of this bug. ***
ia64 stable :)