[Pkg-clamav-devel] ClamAV. again

[Stephen Gran]

This one time, at band camp, Stephen Gran said:
> This one time, at band camp, Devin Carraway said:
> > On Fri, Sep 05, 2008 at 05:06:30PM +0100, Stephen Gran wrote:
> > > I realize none of these are critical vulnerabilities, so if you don't
> > > want me to upload, that's fine.  The upload is prepared if you want it.
> > [...]
> > > +  * [CVE-2008-3912]: libclamav/mbox.c, libclamav/message.c: out-of-memory null
> > > +    dereferences
> > > +  * [CVE-2008-3914]: libclamav/htmlnorm.c, libclamav/others.c,
> > > +    libclamav/sis.c: fd leaks
> > > +  * [CVE-2008-3913]: freshclam/manager.c: memory leaks
> > 
> > CVE-2008-3912 and CVE-2008-3913 don't seem critical on the face of it, but do
> > you know the (normal or induceable) rate of fd leakage caused by
> > CVE-2008-3914?  Reviewing the patch it looks like it's correcting the
> > detection of error cases; if an error on one fd can prevent the closing of
> > another then it's definitely a leak, but whether that leak poses a thread
> > worth fixing in stable seems to depend on whether it could be induced
> > remotely (or if it happens under common conditions; leaking 1 fd per HTML
> > message wouldn't be tolerable, since many mailservers will exhaust the fd
> > limit within a day or two at that rate.  Do you have any more detail?
> 
> Not yet, no.  I'll try to take a look later and see how often they seem
> likely to be called (the functions in sis.c and htmlnorm.c do seem to be
> called roughly once for every matching file type, so my guess is that it
> is likely very often, but I need to actually look to be sure).

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.

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.

I leave the decision up to you.

Cheers,
-- 
 -----------------------------------------------------------------
|   ,''`.                                            Stephen Gran |
|  : :' :                                        sgran at debian.org |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-clamav-devel/attachments/20080913/9c29aba5/attachment.pgp