On Thu, 27 Nov 2003 at 23:54:14 +0100, Tomasz Kojm wrote:Sorry for being the devil's advocate again, but:
On Thu, 27 Nov 2003 18:03:06 +0900 Jerome Schlumberger <[EMAIL PROTECTED]> wrote:
Can someone explain me about the libclamav/scanners.c and this value at the line 64 ? Should I increase it again ?
Please set it to 70 - we need to find an optimal value.
Just to remind the fragment we are talking about :-) :
#define ZIPOSDET 20 /* FIXME: Make it user definable */
When someone reported problem with "Oversized Zip", it was adviced to increase the value to 50.
Now the suggestion is 70.
I've got some drastic, but a real-life example. On one of systems I know, a parameter "maximum compression ratio" in some AV scanner had to be increased up to 200 (AFAIR due to zipped .bmp files). Surprisingly, it wasn't enough! It had to be further increased up to 220, this time due to some database files.
I have also seen stopped .doc files compressed with ratio 236.
And .dbf files with ratio 1101. Also, .wav files with ratio 1182.
Users send quite strange things. So an admin may be forced to set ZIPOSDET for some big value.
I think that this parameter should be made runtime configurable (in clamav.conf). Not every site compiles Clamav on its own.
Isn't it in general a bad idea to make assumptions on "normal" compression ratios?
Shouldn't this be handled within zzip-lib using our resource-limiting parameters?
Or should we add another parameter (eg ArchiveBadFilesize) and make clamav emit an CL_VIRUS for archive members larger than that?
Thomas
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Clamav-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/clamav-users
