Has been posted on oss-security:
we should ask for stabilization of 0.95.1
did maintainers agree to stabling?
(In reply to comment #4)
> did maintainers agree to stabling?
I asked on bug 264834 already for 0.95, but didn't get an answer.
Bottom line, bug 264820 and bug 264836 might block stabling.
as far as I'm concerned it can be marked stable, but what about the bugs which block 0.95* .. do we wait for them or not?
adding blockers .. duno if we should just push this one to stable first anyway or not .. your call email@example.com ;)
(In reply to comment #6)
> as far as I'm concerned it can be marked stable, but what about the bugs which
> block 0.95* .. do we wait for them or not?
bug 264836 :
Nothing in the tree depends on dev-perl/ClamAV. It is broken after each clamav bump. So i guess every user knows that it is broken most of time.
bug 264842 :
Nothing depends on dev-python/pyclamav.
then in that case i did fix the only real blocker just now by sorting uclibc problem out .. :D
Stable for HPPA.
this will also break klamav
i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/kde/3.5/include -I/usr/qt/3/include -I. -I/usr/kde/3.5/include -DQT_THREAD_SUPPORT -D_REENTRANT -DNDEBUG -O2 -O2 -march=i686 -pipe -c options.c
clamdmail.c: In function 'clamdscan':
clamdmail.c:99: error: storage size of 'limits' isn't known
clamdmail.c:164: error: 'CL_EIO' undeclared (first use in this function)
clamdmail.c:164: error: (Each undeclared identifier is reported only once
clamdmail.c:164: error: for each function it appears in.)
clamdmail.c:183: warning: passing argument 2 of 'cl_load' from incompatible pointer type
clamdmail.c:204: error: invalid application of 'sizeof' to incomplete type 'struct cl_limits'
clamdmail.c:214: error: 'CL_ARCHIVE' undeclared (first use in this function)
clamdmail.c:214: error: 'CL_MAIL' undeclared (first use in this function)
clamdmail.c:214: error: 'CL_OLE2' undeclared (first use in this function)
clamdmail.c:214: error: too many arguments to function 'cl_scandesc'
make: *** [clamdmail.o] Error 1
make: *** Waiting for unfinished jobs....
make: Leaving directory `/var/tmp/portage/app-antivirus/klamav-0.44/work/klamav-0.44-source/klamav-0.44/src/klammail'
make: *** [all-recursive] Error 1
make: Leaving directory `/var/tmp/portage/app-antivirus/klamav-0.44/work/klamav-0.44-source/klamav-0.44/src'
make: *** [all-recursive] Error 1
make: Leaving directory `/var/tmp/portage/app-antivirus/klamav-0.44/work/klamav-0.44-source/klamav-0.44'
make: *** [all] Error 2
Hi, what is the state of this bug?
The current stable version of ClamAV is vulnerable to DOS (see #264834) and possibly executes code via a buffer overflow (this bug, http://www.vupen.com/english/advisories/2009/0985 classified this as critical).
The only blocker for stabilization seems to be #264952, but should be a logging problem only (cf. Comment #8).
As far as i'm concerned the clamav-milter bug is not reallz a blocker and can be ignored as far as this security bump goes.
Stable on alpha.
Where are we here. What about the problem cited in comment #11. If we want to proceed, can someone put a definitive stabilize foo-x.y.z in here.
*** Bug 267246 has been marked as a duplicate of this bug. ***
The CLI_ISCONTAINED macro in libclamav/others.h in ClamAV before
0.95.1 allows remote attackers to cause a denial of service
(application crash) via a malformed file with UPack encoding.
Considering that it wouldn't be an uncommon scenario to pipe all incoming mail through clamav, and this is a remote execution vulnerability, this seems like something that should be resolved immediately.
What is the opinion of the maintainer on comment 11? Is it ok to stabilize this?
There we go, all packages depending on clamav should be ready for 0.95 now (took the liberty to fix pyclamav *cough*). (also cc'ing maintainers of depending packages, please speak up soonish if one of the listed packages isn't ready to be stabilized *now*)
Therefore we need to stabilize:
plus for amd64 sparc ia64 x86:
and for ppc amd64 ppc64 sparc x86:
and for x86 only:
As Tobias listed in the above comment, klamav was bumped on bug 264887 to 0.4.6 which supports clamav-0.95.1.
amd64 stable, all arches done.
All arches done, ready for vote. I vote YES.
Yes, too. Someone already filed a request. ;)
Shouldn't this be closed now ??
err, GLSA 200909-04