Re: [Clamav-users] Cherishing my ignorance - An appeal to package rs
On Fri, 2006-11-10 at 11:06 -0500, Jim Maul wrote: In fact, apache, a far more common application than ClamAV, requires vastly more after-install configuration and management effort than does ClamAV, so his premise is farcical. Yes, but will it WORK without this after-install configuration and management? Yes, it will. I promised myself I wouldn't stick my nose into this overgrown monstrosity of a thread, but I cannot resist. I don't condone ignorance, nor do I condone elitism, but in this particular instance I see a rather large point being missed by the OP's sympathisers. If I remember rightly, when I installed ClamAV on Gentoo, it did just work - in the sense that I could run /etc/init.d/clamd start and ClamD would start, and in the sense that the library and header files were installed in sane locations. However... nothing was actually scanning anything for viruses! ClamAV is a toolkit and a service, not a mail scanner or a web-page scanner or an on-access file scanner in its own right. It's one thing having a package that installs and works, but working from a functional point of view is a separate issue from doing what the user wants. The critical point here is that what the user wants can be one of an unlimited number of things, precisely because ClamAV is a means to an end, not the end itself. Those familiar with Windows may think of it this way: ClamAV itself is more like a collection of DLLs, and NOT - for example - an end-product like Norton AntiVirus. (Yes, I am aware of ClamWin, but we are debating the ClamAV package itself here. The two are not the same product.) -- Philip Allison Developer SmoothWall Ltd. - http://www.smoothwall.net/ This email and any attachments transmitted with it are confidential to the intended recipient(s) and may not be communicated to any other person or published by any means without the express permission of SmoothWall Ltd. Any views expressed in this message are solely those of the author. See http://www.smoothwall.net/emailnotice.html for the full text of this notice. This email has been processed by SmoothZap - www.smoothwall.net ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Archive limits completely ignored if ArchiveBlockMax disabled; some scanners not implementing limits at all
Hullo!
I have noticed some disturbing behaviour in ClamAV (0.88.5 and earlier)
regarding the various archive scanning limits (ArchiveMaxFiles,
ArchiveMaxFileSize etc.). What I have noticed is that when
ArchiveBlockMax is not enabled, ClamD can take a very long time to
process files which are above the limits - files which it blocks almost
instantaneously when ArchiveBlockMax is enabled. Looking at the code of
scanners.c, it would appear that some of the limits are completely
ignored when ArchiveBlockMax is not enabled, and so there is not
actually any DoS protection in place.
Here's an example of a piece of code that worries me:
if(limits-maxfilesize ((unsigned int) zdirent.st_size
limits-maxfilesize)) {
cli_dbgmsg(Zip: %s: Size exceeded (%d, max: %ld)\n,
zdirent.d_name, zdirent.st_size, limits-maxfilesize);
/* ret = CL_EMAXSIZE; */
if(BLOCKMAX) {
*virname = Zip.ExceededFileSize;
ret = CL_VIRUS;
break;
}
continue; /* continue scanning */
}
Also, only the Zip and RAR scanners appear to obey ArchiveMaxFiles and
ArchiveMaxCompressionRatio (the latter not actually being controlled by
ArchiveBlockMax). This inconsistency is not warned about in the
documentation.
I have implemented ClamD integration for SmoothGuardian, our web
filtering product, which currently ships with ArchiveBlockMax enabled.
Whilst we have yet to receive any bug reports moaning about oversized
archives or similar, it would be nice if we could give more control over
ClamD to the end user; however, I am not confident in allowing customers
to turn off ArchiveBlockMax if this will completely disable the denial
of service protection the limits provide.
In my opinion, the option should simply disable whether or not archives
that break limits are treated as viruses; the scanner should still exit
early if the limits are broken.
Any comments? What is the official verdict on what scanners should do
with the limits when ArchiveBlockMax is disabled, and what are the
scanners *actually* doing at the moment?
Regards,
Phil
--
Philip Allison
Developer
SmoothWall Ltd. - http://www.smoothwall.net/
This email and any attachments transmitted with it are confidential to
the intended recipient(s) and may not be communicated to any other
person or published by any means without the express permission of
SmoothWall Ltd. Any views expressed in this message are solely those of
the author. See http://www.smoothwall.net/emailnotice.html for the full
text of this notice.
This email has been processed by SmoothZap - www.smoothwall.net
___
http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Archive limits completely ignored if ArchiveBlockMax disabled; some scanners not implementing limits at all
On Thu, 2006-11-02 at 17:50 +0100, Tomasz Kojm wrote:
if(limits-maxfilesize ((unsigned int) zdirent.st_size
limits-maxfilesize)) { cli_dbgmsg(Zip: %s: Size exceeded (%d, max:
%ld)\n, zdirent.d_name, zdirent.st_size, limits-maxfilesize); /* ret =
CL_EMAXSIZE; */ if(BLOCKMAX) {
*virname = Zip.ExceededFileSize;
ret = CL_VIRUS;
break;
}
continue; /* continue scanning */
^-- the archive scanning is continued but the file is
skipped
}
Apologies - upon closer inspection, I see what you mean. :)
So one basically ends up with partially scanned archives, yes? As in
some of the files within the archive scanned, and some not?
You're posting to the wrong mailing list.
Sorry, I should probably be posting to a C beginner's list with
oversights like that one ;) My tone may have come across as accusatory,
but it wasn't meant that way; it was meant more as a what's going on
here then? type of post.
I think I see the source of my confusion - looking at the BZip2 and GZip
scanners, the decompression loop is separate from the actual scanning; I
was applying the same assumption to the Zip code, but this isn't
correct, as the decompression methods differ (bzip/gzip being
stream-oriented instead of extracting discrete files). Is a .tar.gz file
that hits the archive limits also partially scanned (assuming the
answer to my earlier question is yes) if ArchiveBlockMax is disabled? In
my experience, ClamD certainly takes a long time doing something in this
case, it's just never been entirely clear to me exactly what.
(I'll happily take this to the devel list if you like, but I'm not
subscribed to it at time of writing.)
--
Philip Allison
Developer
SmoothWall Ltd. - http://www.smoothwall.net/
This email and any attachments transmitted with it are confidential to
the intended recipient(s) and may not be communicated to any other
person or published by any means without the express permission of
SmoothWall Ltd. Any views expressed in this message are solely those of
the author. See http://www.smoothwall.net/emailnotice.html for the full
text of this notice.
This email has been processed by SmoothZap - www.smoothwall.net
___
http://lurker.clamav.net/list/clamav-users.html
