Re: segfault using cl_scanfile

On Fri, 30 Apr 2004 15:49:35 -0700
Alex Krohn <alex-clamav <at> gossamer-threads.com> wrote:

> Hi,
> 
> This came from a user of Mail::ClamAV and I narrowed it down to simple
> C code that causes the segv. I've attached the c code and the text
> file that causes it to seg fault. Is there something wrong with my
> test code, or is this a bug in clamav?
> 
> Compiled with:
> 	/usr/bin/gcc clamav-test.c -o clamav-test -lclamav
> 
> Here is a bt:
> 

You forgot to build the trie (cl_buildtrie(root)) before calling
cl_scanfile().

--

-- 
   oo    .....         Tomasz Kojm <tkojm <at> clamav.net>
  (\/)\.........         http://www.ClamAV.net/gpg/tkojm.gpg
     \..........._         0DCA5A08407D5288279DB43454822DC8985A444B
       //\   /\              Sat May  1 11:21:06 CEST 2004

Re: different approach to streammaxlength

On Thu, 29 Apr 2004 07:37:25 -0400
Joe Maimon <jmaimon <at> ttec.com> wrote:

> Could we maybe consider doing it this way?
> 
> This patch fixes clamd to stop after reading EXACTLY up to
> streammaxlength. After reaching streammaxlength, whatever has been
> received up to that point is scanned.
> 
> I have been using this patch for over a month now with perfect
> results.

[...]

> +	    if(maxsize && (size + btread > maxsize)) (*)
> +		    btread = (maxsize - size); /* only read up to max */
> +	    if (!btread) {
> +		logg("^ScanStream: Size limit reached ( max: %d)\n", maxsize);
> +	    	break; /* Scan what we have */
> +	    }

The patch seems to be OK but in my opinion in (*) we must also test for
an equality. Included (with the mentioned change) in CVS. Thanks.

BTW: Please don't cross-post your patches.

--

-- 
   oo    .....         Tomasz Kojm <tkojm <at> clamav.net>
  (\/)\.........         http://www.ClamAV.net/gpg/tkojm.gpg
     \..........._         0DCA5A08407D5288279DB43454822DC8985A444B

Re: Encrypted zip scanning..

On Fri, 16 Apr 2004 21:52:02 +0000 (GMT)
Andy Fiddaman <clam <at> fiddaman.net> wrote:

> 
> At the moment, if the detect-encrypted option is set and a file in a
> zip is encrypted, then none of the following files nor the entire zip
> are scanned for virii.
> 
> What do people think about changing this behaviour ? The reason is
> that I allow my users to choose whether they want to block encrypted
> archives or not; I look at the response from Clam and do something
> like:
> 
> if (response ~ /^Encrypted./ &&
> user_wants_to_block_encrypted_archives)
>  .. block
> else
>  .. allow
> fi
> 
> The problem is that the users who opt to receive encrypted archives
> would still like me to block those which are known to be viral (i.e.
> those which are detected with the current general signatures).
> 
> To implement this, I've applied the attached patch which works for me.
> I don't think it's clean enough to apply to the existing code but
> would appreciate any comments (In particular, I don't like adding an
> extra return status from the scanners..)

Feature implemented (in a different way than your patch) in CVS for both

Re: Encrypted zip scanning..

On Sat, 1 May 2004, Tomasz Kojm wrote:
; Feature implemented

Thanks!

; (in a different way than your patch)

No surprise there - I wasn't happy with my way of doing it, I'll take
a look in CVS

; in CVS for both RAR and zip archives. Thanks for the idea.

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: different approach to streammaxlength

Tomasz Kojm wrote:

>On Thu, 29 Apr 2004 07:37:25 -0400
>Joe Maimon <jmaimon <at> ttec.com> wrote:
>
>  
>
>>Could we maybe consider doing it this way?
>>
>>This patch fixes clamd to stop after reading EXACTLY up to
>>streammaxlength. After reaching streammaxlength, whatever has been
>>received up to that point is scanned.
>>
>>I have been using this patch for over a month now with perfect
>>results.
>>    
>>
>
>[...]
>
>  
>
>>+	    if(maxsize && (size + btread > maxsize)) (*)
>>+		    btread = (maxsize - size); /* only read up to max */
>>+	    if (!btread) {
>>+		logg("^ScanStream: Size limit reached ( max: %d)\n", maxsize);
>>+	    	break; /* Scan what we have */
>>+	    }
>>    

updated snprintf patchset from CVS

Here is an updated copy of the sprintf -> snprintf  conversion patch.

Phil.

(well I hope it's attached.. this new thunderbird build seems a bit wacked)

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: updated snprintf patchset from CVS

blah.. munged my headers the 2nd time..  here is the patch if the other email
doesnt get through quickly.

Phil.

On Mon, May 03, 2004 at 08:51:22PM -0600, Phil Oleson wrote:
> Here is an updated copy of the sprintf -> snprintf  conversion patch.
> 
> Phil.
> 
> (well I hope it's attached.. this new thunderbird build seems a bit wacked)
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE. 
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Clamav-devel mailing list
> Clamav-devel <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/clamav-devel

Index: clamav-milter/clamav-milter.c
===================================================================
RCS file: /cvsroot/clamav/clamav-devel/clamav-milter/clamav-milter.c,v
retrieving revision 1.85
diff -u -r1.85 clamav-milter.c
--- clamav-milter/clamav-milter.c	29 Apr 2004 07:35:27 -0000	1.85

Virus submissions..

I've got a zip containing 23 viruses which aren't detected by ClamAV with
the latest signatures and source from CVS 2/5 (May).

I've tried to submit it to the web interface but just got a blank screen
back, can anyone from the team confirm that it has arrived, or let me know
where I can email the file to ?

Thanks,

Andy

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

RE: Virus submissions..

> -----Original Message-----
> From: clamav-devel-admin <at> lists.sourceforge.net [mailto:clamav-devel-
> admin <at> lists.sourceforge.net] On Behalf Of Andy Fiddaman
> Sent: 5. maj 2004 12:55
> To: clamav-devel <at> lists.sourceforge.net
> Subject: [Clamav-devel] Virus submissions..
> 
> 
> I've got a zip containing 23 viruses which aren't detected by ClamAV
with
> the latest signatures and source from CVS 2/5 (May).
> 
> I've tried to submit it to the web interface but just got a blank
screen
> back, can anyone from the team confirm that it has arrived, or let me
know
> where I can email the file to ?
> 

I can confirm that, we've received your sample(s).

Thank you...

Best regards,
Diego d'Ambra

Error "Out of memory: cannot allocate memory" fixed

Well, not *exactly* fixed...

I started to get this error after performing an upgrade from 0.68 to 0.70 
(see my post 04/21/2004).  I made no changes to my autoconf options, and 
no changes to my clamav.conf (apart from ThreadTimeout --> ReadTimeout). 
v0.70 would cause sendmail to error upon connection from an smtp client 
with the "Out of memory: cannot allocate memory" error.  v0.68 does not do 
this.

After seeing a post about this error being caused by the socket name being 
wrong, I did a bit of troubleshooting on another system and found it was a 
permissions problem on the directory where the socket lies 
(/var/local/clamav).

Here are the particulars (Pease note, this this test system is running 
clamav-milter, not mimedefang, I'm just running as mimedefang.  Another 
system exhibiting the same problem is running as clamav):

clamav is complied as follows:

./configure --enable-milter \
        --enable-debug \
        --with-user=mimedefang \
        --with-group=mimedefang \
        --with-gnu-ld \
        --disable-clamuko \
        --sysconfdir=/etc/clamav \
        --localstatedir=/var/local/clamav \
        --with-dbdir=/var/local/clamav