[Pkg-clamav-devel] ClamAV. again

[Devin Carraway]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Sep 13, 2008 at 03:25:25PM +0100, Stephen Gran wrote:
> So, after some investigation, it looks like the following is the case
> for CVE-2008-3914:
> 
> In some error paths, we could potentially leak two fds in file copy
> routines (unlikely but possible - malloc failure paths).  
> 
> We could leak another fd for sis files in similar circumstances.

Probably not exploitable unless combined with a memory exhaustion bug
elsewhere, then.  However, if combined with such a bug, it could turn a
momentary DoS into a permanent one.


> In html normalization routines, we will potentially leak one fd, and
> we could close fds that are not open.  I don't believe the close will
> cause a real issue in practice (my tests show that c programs do not
> abort when close is called on a non-existant fd - EBADF is ignored).
> The one fd leak is due to a wrong test for an open fd in a path that
> is taken when analyzing embedded javascript in html.  I'm not sure how
> often this is going to be hit, in practice.

Closing a bad file descriptor is harmless, as you say.  Closing one that
the scanner still needs could cause a DoS, but it seems likely to be
deterministic, and if it were closing anything important it would have
surfaced as a DoS already.  However, leaking an fd when scanning javascript is
serious enough to be a showstopper for the package.  Embedding javascript in
email (the main case I'm aware of where clamav would be exposed to it) may not
be legitimate or useful, but a scan of my spam folder suggests that it's
pretty common anyway.

This is a bit less exploitable than the unpacker bug we handled a while back,
but if one fd can leak per HTML+JS object scanned, it's still not unduly
difficult -- a multipart message with a thousand HTML attachments would be
well within the size limits of most MTAs, and it would require only a few
hundred of those to exceed the default fd limit.  Moreover, even when not
being specifically targeted, such a bug will cause clamd to die after a few
days or weeks exposed to a spam stream.

At any rate, it's another of those cases where there isn't a direct threat
from the vulnerability, but where a weakness can cause a security measure
itself to fail.  If exploitation is practicable, as it seems to be, I think we
should fix it.

Do you have patches/packages handy, or should I prepare some?

- -- 
Devin  \ aqua(at)devin.com, IRC:Requiem; http://www.devin.com
Carraway \ 1024D/E9ABFCD2: 13E7 199E DD1E 65F0 8905 2E43 5395 CA0D E9AB FCD2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIzWF7U5XKDemr/NIRAlh7AJ9q/3+/hN9ZeLpLIIF9V3VfuR6xGACeO/JF
T6sgjz3TvUekEaf2qnwWOOI=
=8Ejf
-----END PGP SIGNATURE-----