Bugzilla Bug 213762

Secunia:
The vulnerability is caused due to a boundary error within the
"cli_scanpe()" function in libclamav/pe.c. This can be exploited to
cause a heap-based buffer overflow via a specially crafted "Upack"
executable.

ClamAV upstream will not fix this vulnerability in their 0.92 branch, but
*after* 0.93 has been released, soon in one of their updates.

No patches are available at this time, scanning using this module has been
disabled. Embargo date is currently 2008-04-09.

any update on the timeline, since the embargo date has passed?

Can't see any 0.93 release yet...

The issue is now public, new version should be out soon hopefully

http://secunia.com/secunia_research/2008-11/advisory/

CC'ing infra, since clamav is also used here iirc

0.93 is out!
http://freshmeat.net/redir/clamav/29355/url_tgz/clamav-0.93.tar.gz

*** Bug 217771 has been marked as a duplicate of this bug. ***

There are hangs and crashes too.

http://svn.clamav.net/svn/clamav-devel/trunk/ChangeLog

Mon Apr 14 21:35:11 CEST 2008 (tk)
----------------------------------
  * Check in 0.93 patches:
    - libclamunrar: bb#541 (RAR - Version required to extract - Evasion)
    - libclamav/spin.c: bb#876 (PeSpin Heap Overflow Vulnerability)
    - libclamav/pe.c: bb#878 (Upack Buffer Overflow Vulnerability)
    - libclamav/message.c: bb#881 (message.c: read beyond allocated region)
    - libclamav/unarj.c: bb#897 (ARJ: Sample from CERT-FI hangs clamav)
    - libclamunrar: bb#898 (RAR crashes on some fuzzed files from CERT-FI)

I pushed 0.93 in portage. I had to use AT_M4DIR="m4", see
www.gossamer-threads.com/lists/clamav/devel/37726


Hi arches, please test clamav-0.93 and mark stable if OK.

That's odd. Right after installation I get this:
# clamd
clamd: error while loading shared libraries: libclamunrar_iface.so.3: cannot
open shared object file: No such file or directory
# ldd `which clamd`|less
        libclamav.so.4 => /usr/lib/libclamav.so.4 (0x4048d000)
        libz.so.1 => /lib/libz.so.1 (0x40364000)
        libbz2.so.1 => /lib/libbz2.so.1 (0x4008d000)
        libgmp.so.3 => /usr/lib/libgmp.so.3 (0x400e1000)
        libclamunrar_iface.so.4 => /usr/lib/libclamunrar_iface.so.4
(0x4088f000)
        libclamunrar.so.4 => /usr/lib/libclamunrar.so.4 (0x4026f000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x402e4000)
        libc.so.6 => /lib/libc.so.6 (0x40609000)
        /lib/ld.so.1 (0x400a1000)
        libclamunrar_iface.so.3 => not found

It's linked to both libclamunrar_iface.so.3 and libclamunrar_iface.so.4? Should
be easy to fix...

same bug over here!

*** Bug 217809 has been marked as a duplicate of this bug. ***

(In reply to comment #8)
> I pushed 0.93 in portage. I had to use AT_M4DIR="m4", see
> www.gossamer-threads.com/lists/clamav/devel/37726
> 
> 
> Hi arches, please test clamav-0.93 and mark stable if OK.
> 

No, the current ebuild is not ready for general consumption. I came across this
libunrar weirdness last night, but it was getting late, so I plan to work on it
today. BTW, it builds just fine when no clamav is installed, so there might be
some glitch in the build system - using libclamunrar_iface.so installed on
system if it exists (e.g. if clamav-0.92.1 is installed, which had
libclamunrar_iface.so.3).

Also, iconv configure option has been added, and some other minor stuff. I will
let you know when an ebuild is ready. Masked it for now.

OK, back to [ebuild] status.

I can't reproduce that behaviour while upgrading frop 0.92.1 to 0.93.
Everything was fine on two different boxes. I also tried upgrading from
0.92.1-r1 to 0.93.

[falco:/usr/local/portage/app-antivirus]130# /usr/bin/ldd /usr/sbin/clamd
        linux-gate.so.1 =>  (0xb7f05000)
        libclamav.so.4 => /usr/lib/libclamav.so.4 (0xb7e7c000)
        libz.so.1 => /lib/libz.so.1 (0xb7e6b000)
        libgmp.so.3 => /usr/lib/libgmp.so.3 (0xb7e3c000)
        libclamunrar_iface.so.4 => /usr/lib/libclamunrar_iface.so.4
(0xb7e38000)
        libclamunrar.so.4 => /usr/lib/libclamunrar.so.4 (0xb7e2e000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7e17000)
        libc.so.6 => /lib/libc.so.6 (0xb7ce6000)
        /lib/ld-linux.so.2 (0xb7f06000)


If that upgrade is really a problem then we will backport the patch on 0.92.1.
i'm attaching it.

Created an attachment (id=149826) [edit]
patch from svn, revision 3788

(In reply to comment #12)
> BTW, it builds just fine when no clamav is installed, so there might be
> some glitch in the build system - using libclamunrar_iface.so installed on
> system if it exists (e.g. if clamav-0.92.1 is installed, which had
> libclamunrar_iface.so.3).

It also builds fine when the same version is already installed. And yes, it
certainly is a build system issue (libtool?).

OK, this is a bit too complicated for me. For some reason, libclamav links to
libclamunrar and libclamunrar_iface libraries which are installed on system
(/usr/lib), in addition to freshly compiled ones in working dir.

Thing is, I have no idea why, or how to fix it. Can anyone bit better skilled
with libtool lend a hand here? Otherwise, I'm just going to wait for maintainer
or $someone to fix it, before I can add an ebuild do the tree...

(In reply to comment #16)
> OK, this is a bit too complicated for me. For some reason, libclamav links to
> libclamunrar and libclamunrar_iface libraries which are installed on system
> (/usr/lib), in addition to freshly compiled ones in working dir.

Which is weird is that i can't reproduce that behaviour... even from 0.92.1,
even from 0.92.1-rc1...

What i can do is to (try to) backport the patches for 0.92.1

... i finally managed to find a way to reproduce the bug: by using bash instead
of zsh. I'm investigating.

During the "install" phase, a command introduces a
./work/clamav-0.93/libclamav/.libs/libclamav.so.4.0.1T file that contains a
reference to the old libclamunrar_iface.so.3.

The command that introduces this reference is:

(cd /data/var/tmp/portage/app-antivirus/clamav-0.93/work/clamav-0.93/libclamav;
/bin/sh ../libtool  --tag=CC --mode=relink i686-pc-linux-gnu-gcc -O2
-march=pentium4 -fomit-frame-pointer -thread-safe -version-info 4:1:0
-no-undefined -Wl,--version-script,../libclamav/libclamav.map -o libclamav.la
-rpath /usr/lib matcher-ac.lo matcher-bm.lo matcher.lo md5.lo others.lo
readdb.lo cvd.lo dsig.lo str.lo scanners.lo textdet.lo filetypes.lo rtf.lo
blob.lo mbox.lo message.lo table.lo text.lo ole2_extract.lo vba_extract.lo
msexpand.lo pe.lo upx.lo htmlnorm.lo chmunpack.lo rebuildpe.lo petite.lo
wwunpack.lo unsp.lo aspack.lo packlibs.lo fsg.lo mew.lo upack.lo line.lo
untar.lo unzip.lo inflate64.lo special.lo binhex.lo is_tar.lo tnef.lo autoit.lo
strlcpy.lo regcomp.lo regerror.lo regexec.lo regfree.lo unarj.lo bzlib.lo
nulsft.lo infblock.lo pdf.lo spin.lo yc.lo elf.lo sis.lo uuencode.lo
phishcheck.lo phish_domaincheck_db.lo phish_whitelist.lo regex_list.lo
mspack.lo cab.lo entconv.lo hashtab.lo dconf.lo lzma_iface.lo explode.lo
textnorm.lo -lz -L/usr/lib -lbz2 -L/usr/lib -lgmp -lpthread lzma/liblzma.la
../libclamunrar_iface/libclamunrar_iface.la -inst-prefix-dir
/data/var/tmp/portage/app-antivirus/clamav-0.93/image/) 

I'm not sure, but note the double "-L/usr/lib"

After that command, i have a new libclamav.so.4.0.1T :
$ find -name "libclamav.so*" -type f
./work/clamav-0.93/libclamav/.libs/libclamav.so.4.0.1
./work/clamav-0.93/libclamav/.libs/libclamav.so.4.0.1T

which contains the evil:

$ strings ./work/clamav-0.93/libclamav/.libs/libclamav.so.4.0.1T|grep iface
libclamunrar_iface.so.3

Created an attachment (id=150084) [edit]
Fix against 0.93 compilations issues wrt unrar_iface.so.3

I removed these extra -L/usr/lib. That works very fine, but that's dirty. See
the patch and comment...

Dirty, but works. updated 0.93 ebuild committed and unmasked.

Okay, let's try again, dear arches!

target: 
clamav-0.93 alpha amd64 hppa ia64 ppc ppc64 sparc x86

What should be tried is emerging 0.93 while having 0.92.1 (or its -r1, doesn't
matter) installed, and then checking dynamic linking. Stuff from comment #9
must not happen.

This will break klamav. Maybe other reverse deps won't work, too - I only
tested klamav. Happens on amd64/x86.

make[3]: Leaving directory
`/var/tmp/portage/app-antivirus/klamav-0.42/work/klamav-0.42-source/klamav-0.42/src/sqlite'
Making all in klammail
make[3]: Entering directory
`/var/tmp/portage/app-antivirus/klamav-0.42/work/klamav-0.42-source/klamav-0.42/src/klammail'
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 clamdmail.c
clamdmail.c: In function 'clamdscan':
clamdmail.c:210: error: 'struct cl_limits' has no member named 'maxmailrec'
clamdmail.c:211: error: 'struct cl_limits' has no member named 'maxratio'
make[3]: *** [clamdmail.o] Error 1
make[3]: Leaving directory
`/var/tmp/portage/app-antivirus/klamav-0.42/work/klamav-0.42-source/klamav-0.42/src/klammail'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/var/tmp/portage/app-antivirus/klamav-0.42/work/klamav-0.42-source/klamav-0.42/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/var/tmp/portage/app-antivirus/klamav-0.42/work/klamav-0.42-source/klamav-0.42'
make: *** [all] Error 2
 * 
 * ERROR: app-antivirus/klamav-0.42 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called src_compile
 *             environment, line 4137:  Called kde_src_compile
 *             environment, line 2858:  Called kde_src_compile 'src_compile'
 *             environment, line 2978:  Called kde_src_compile 'src_compile'
'all' 'myconf'
 *             environment, line 2974:  Called die
 * The specific snippet of code:
 *                   emake || die "died running emake, $FUNCNAME:make"
 *  The die message:
 *   died running emake, kde_src_compile:make

(In reply to comment #22)
> What should be tried is emerging 0.93 while having 0.92.1 (or its -r1, doesn't
> matter) installed, and then checking dynamic linking. Stuff from comment #9
> must not happen.

It's still happening with CVS revision 1.2:
elmer ~ # qlop -lu clamav | tail -n 2
Thu Apr 17 22:13:41 2008 >>> app-antivirus/clamav-0.92.1
Fri Apr 18 05:58:55 2008 >>> app-antivirus/clamav-0.93
elmer ~ # ldd `which clamd`
        libclamav.so.4 => /usr/lib/libclamav.so.4 (0x40213000)
        libz.so.1 => /lib/libz.so.1 (0x40364000)
        libbz2.so.1 => /lib/libbz2.so.1 (0x4008d000)
        libgmp.so.3 => /usr/lib/libgmp.so.3 (0x400e1000)
        libclamunrar_iface.so.4 => /usr/lib/libclamunrar_iface.so.4
(0x4061f000)
        libclamunrar.so.4 => /usr/lib/libclamunrar.so.4 (0x4033d000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x402e4000)
        libc.so.6 => /lib/libc.so.6 (0x40a09000)
        /lib/ld.so.1 (0x400a1000)
        libclamunrar_iface.so.3 => not found
elmer ~ # qfile `which clamd`
app-antivirus/clamav (/usr/sbin/clamd)

(In reply to comment #24)

> 
> It's still happening with CVS revision 1.2:
> elmer ~ # qlop -lu clamav | tail -n 2
> Thu Apr 17 22:13:41 2008 >>> app-antivirus/clamav-0.92.1
> Fri Apr 18 05:58:55 2008 >>> app-antivirus/clamav-0.93
> elmer ~ # ldd `which clamd`
>         libclamav.so.4 => /usr/lib/libclamav.so.4 (0x40213000)
>         libz.so.1 => /lib/libz.so.1 (0x40364000)
>         libbz2.so.1 => /lib/libbz2.so.1 (0x4008d000)
>         libgmp.so.3 => /usr/lib/libgmp.so.3 (0x400e1000)
>         libclamunrar_iface.so.4 => /usr/lib/libclamunrar_iface.so.4
> (0x4061f000)
>         libclamunrar.so.4 => /usr/lib/libclamunrar.so.4 (0x4033d000)
>         libpthread.so.0 => /lib/libpthread.so.0 (0x402e4000)
>         libc.so.6 => /lib/libc.so.6 (0x40a09000)
>         /lib/ld.so.1 (0x400a1000)
>         libclamunrar_iface.so.3 => not found
> elmer ~ # qfile `which clamd`
> app-antivirus/clamav (/usr/sbin/clamd)
> 

Can you post somewhere the output of the install phase, please. Or just the
"libtool ... -o libclamav.la ..." line.

Is someone else able to trigger that stuff?

Works for me now, thanks. :)

(In reply to comment #25)
> (In reply to comment #24)
> 
> > 
> > It's still happening with CVS revision 1.2:
> > elmer ~ # qlop -lu clamav | tail -n 2
> > Thu Apr 17 22:13:41 2008 >>> app-antivirus/clamav-0.92.1
> > Fri Apr 18 05:58:55 2008 >>> app-antivirus/clamav-0.93
> > elmer ~ # ldd `which clamd`
> >         libclamav.so.4 => /usr/lib/libclamav.so.4 (0x40213000)
> >         libz.so.1 => /lib/libz.so.1 (0x40364000)
> >         libbz2.so.1 => /lib/libbz2.so.1 (0x4008d000)
> >         libgmp.so.3 => /usr/lib/libgmp.so.3 (0x400e1000)
> >         libclamunrar_iface.so.4 => /usr/lib/libclamunrar_iface.so.4
> > (0x4061f000)
> >         libclamunrar.so.4 => /usr/lib/libclamunrar.so.4 (0x4033d000)
> >         libpthread.so.0 => /lib/libpthread.so.0 (0x402e4000)
> >         libc.so.6 => /lib/libc.so.6 (0x40a09000)
> >         /lib/ld.so.1 (0x400a1000)
> >         libclamunrar_iface.so.3 => not found
> > elmer ~ # qfile `which clamd`
> > app-antivirus/clamav (/usr/sbin/clamd)
> > 
> 
> Can you post somewhere the output of the install phase, please. Or just the
> "libtool ... -o libclamav.la ..." line.
> 
> Is someone else able to trigger that stuff?
> 


Reping Jeroen, can you reproduce it while emerging from 0.92.1?

(In reply to comment #27)
> Reping Jeroen, can you reproduce it while emerging from 0.92.1?

Going from 0.92.1 to 0.93 seems alright. I'll test once more and stabilise for
HPPA when I'm satisfied.

Stable for HPPA.

alpha/ia64/sparc/x86 stable

amd64 stable

This one breaks dansguardian:

x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I..   -I/usr/include
-I/usr/include -fexceptions -O2 -mtune=opteron -march=opteron
-fomit-frame-pointer -pipe  -MT clamdscan.o -MD -MP -MF .deps/clamdscan.Tpo -c
-o clamdscan.o `test -f 'contentscanners/clamdscan.cpp' || echo
'./'`contentscanners/clamdscan.cpp
contentscanners/clamav.cpp: In member function ‘virtual int
clamavinstance::init(void*)’:
contentscanners/clamav.cpp:265: error: ‘struct cl_limits’ has no member
named ‘maxratio’
contentscanners/clamav.cpp:266: error: ‘struct cl_limits’ has no member
named ‘maxratio’
contentscanners/clamav.cpp:267: error: ‘struct cl_limits’ has no member
named ‘maxratio’
make[2]: *** [clamav.o] Error 1
make[2]: *** Waiting for unfinished jobs....
mv -f .deps/dansguardian.Tpo .deps/dansguardian.Po
mv -f .deps/clamdscan.Tpo .deps/clamdscan.Po
mv -f .deps/FOptionContainer.Tpo .deps/FOptionContainer.Po
mv -f .deps/OptionContainer.Tpo .deps/OptionContainer.Po
make[2]: Leaving directory
`/tmp/portage/net-proxy/dansguardian-2.9.9.3_beta/work/dansguardian-2.9.9.3/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/tmp/portage/net-proxy/dansguardian-2.9.9.3_beta/work/dansguardian-2.9.9.3'
make: *** [all] Error 2

did you see the warning during configure ?

config.status: creating docs/man/clamd.conf.5
config.status: creating docs/man/clamdscan.1
config.status: creating docs/man/clamscan.1
config.status: creating docs/man/freshclam.1
config.status: creating docs/man/freshclam.conf.5
config.status: creating docs/man/sigtool.1
config.status: creating clamav-config.h
config.status: executing depfiles commands        
configure: WARNING:
****** WARNING:
****** You are either cross compiling to a different host or
****** you have manually disabled important configure checks.
****** Please be aware that this build may be badly broken.
****** DO NOT REPORT BUGS BASED ON THIS BUILD !!!

make  all-recursive
make[1]: Entering directory
`/var/tmp/portage/app-antivirus/clamav-0.93/work/clamav-0.93'
Making all in libclamunrar

0.93 breaks bug #218510

Should we wait till compile errors with klamav and Mail-ClamAV are fixed?

(In reply to comment #35)
> Should we wait till compile errors with klamav and Mail-ClamAV are fixed?
> 

That's up to the respective maintainers for these packages to decide. Klamav
has a new version since Apr 30th, and there is a patch for Mail-ClamAV
available on abovementioned bug.

Do compile issues in dependent packages warrant holding off on a security
issue?  I don't think so, but I leave that up to you guys.

(In reply to comment #35)
> Should we wait till compile errors with klamav and Mail-ClamAV are fixed?

Please mark 0.93 stable for ppc and ppc64. When other packages are broken due
to the upgrade, and there is a fix available, please mark the corresponding
bugs as blockers of this bug and we will go through a fast stabling of those
packages.

(In reply to comment #37)
> Do compile issues in dependent packages warrant holding off on a security
> issue?  I don't think so [...]

How comes I never had to dicide; now it's clear: Priority(Security) >
Priority(No Breakage of other packages)

ppc64 stable.

ppc stable

glsa request filed.

Fixed in release snapshot. Also fixed Mail-ClamAV and klamav.

Uh, drop my comment about "fixed Mail-ClamAV". It's not fixed. For interested
parties tracker of clamav-0.93 breakages was created in bug #221715.

Arches, please test and mark stable:
=app-antivirus/clamav-0.93.3
Target keywords : "alpha amd64 hppa ia64 ppc ppc64 sparc x86"

gah, wrong bug.

(In reply to comment #45)
> gah, wrong bug.

removing sparc, too

it was GLSA 200805-19 unless i'm wrong. Closing.