security/clamav: Segmentation fault when running clamav in a 32-bit jail on a 64-bit host

[Jeremy Chadwick]

On Fri, Aug 27, 2010 at 01:58:25PM -0400, Glen Barber wrote:
> On 8/27/10 1:32 PM, Jeremy Chadwick wrote:
> >> Of course.  The new backtrace is here: http://gist.github.com/553734
> > 
> > I want to make sure I understand the environment -- on a native i386
> > (32-bit) FreeBSD host, the software works fine.  But on a native amd64
> > (64-bit) FreeBSD host, the software segfaults.  Correct?
> > 
> 
> The clamav instance runs on a 64-bit host in a 32-bit jail.  In a 32-bit
> host/32-bit jail environment, the software runs fine, as you suggest above.
> 
> > If so -- it appears as if the system you're providing the backtrace from
> > is a 32-bit system, or within a 32-bit environment?  I would expect to
> > see 64-bit addresses in the backtrace, yet they're all 32-bit.
> > 
> > I'm not familiar with jailed environments (or the concept/possibility of
> > running a mixed-architecture jail (e.g. 64-bit host OS with 32-bit
> > jails)).  I don't use lib32 on my amd64 systems.
> > 
> 
> To be honest, this is the first non-base software I've had an issue with
> in a mixed-arch environment.

Okay, so it's sort of what I thought.  Your system has a series of
include files on it that are for amd64 (64-bit), but clamav, when built
within a 32-bit jail on that system, is (probably -- no proof, but it's
an educated guess based on what's happening) detecting some 64-bit
pieces through include files and making some incorrect assumptions about
the size of some types.

I'd really need to set up a testbed system/VM and get full instructions
from start to finish on how to set up a 32-bit jail and so on, given
that I've never done it.  Otherwise, you're probably going to need to
find someone who has a similar setup and can reproduce the problem, or
give a developer root-level access to your system.

> > I did take a look at the clamav code itself (I'd have to spend a few
> > hundred lines outlining it here and would rather not).  My guess is that
> > there's a conflict between what the running OS architecture is and what
> > the build process determines the architecture is.
> > 
> > Given that you have jails, and possibly a mixed architecture environment
> > on a single host (e.g. 64-bit host OS with 32-bit jails), can you
> > explain exactly how you go about building clamav, followed by how you go
> > about running it?
> 
> The build is done from ports with no special options excluding the
> latest build, being:
> 
> 	make -DWITH_DEBUG DEBUG_FLAGS=-g
> 
> The only make.conf entry is PERL_VERSION=5.10.1.
> 
> The clamd service runs under djb's supervise (/usr/local/sbin/clamd).
> Additionally, port builds were done after setting UNAME_m and UNAME_p
> [1], but I haven't had luck with that overriding the machine hardware type.
> 
> If this provides any clues, here's what file(1) sees, as well as ldd:
> 
> % file /usr/local/sbin/clamd
> /usr/local/sbin/clamd: ELF 32-bit LSB executable, Intel 80386, version 1
> (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 8.1, not
> stripped
> 
> % ldd /usr/local/sbin/clamd
> /usr/local/sbin/clamd:
>         libclamav.so.7 => /usr/local/lib/libclamav.so.7 (0x280ac000)
>         libz.so.5 => /lib/libz.so.5 (0x281f8000)
>         libbz2.so.4 => /usr/lib/libbz2.so.4 (0x2820a000)
>         libm.so.5 => /lib/libm.so.5 (0x2821b000)
>         libthr.so.3 => /lib/libthr.so.3 (0x28235000)
>         libc.so.7 => /lib/libc.so.7 (0x2824a000)
> 
> [1] - http://www.mail-archive.com/freebsd-amd64@freebsd.org/msg00248.html

Right -- I understand the binary is 32-bit, but that's not where the
problem lies (based on my guess).  The binary obviously runs, or else
you wouldn't be seeing a segfault or even get a remotely coherent
backtrace in gdb.

I'm not sure how to explain this in a way that's easily understandable
(I'm assuming you're not a programmer.  :-) ).  My guess is that during
compile-time, the compiler is kicking out some code that's based on
sizeof(int) == 8 (64-bit), when that shouldn't be the case in a 32-bit
environment.  Include files could cause this problem too.

There may be some "black magic" in the ports infrastructure (maybe even
on a per-port basis) to work around this problem that the clamav port
isn't making use of.  I really don't know.

Sorry I can't be of more help.  I'm one of those guys who if he needs a
32-bit and 64-bit system, buys two physical systems.

-- 
| Jeremy Chadwick                                   jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |