|Main Archive Page > Month Archives > clamav-users archives|
aCaB wrote: > Hi list. > I'm in the process of redesigning the logic of limits in ClamAV. > The rewrite (scheduled for the upcoming 0.93) is aimed at solving, once > for all, the annoyances related to config options like > (clamd.conf-style): ArchiveMaxFileSize, ArchiveMaxRecursion, > ArchiveMaxFiles and so on...
A follow up on this...
The code rework is complete and ready to be tested in 0.93-rc1.
Although our regression results are very satisfactory (increased
detection rate and slightly improved performance) we urge as much users
as possible to test it and to report back so that we can move on to
Please grab it from
http://downloads.sourceforge.net/clamav/clamav-0.93rc1.tar.gz and send back your comments.
Now about the changes in the limits...
The new mechanism is pretty simplified.
For every request to scan a file passed to libclamav from its "clients" (e.g. clamscan, clamd, or 3rd party tools) we determine if the file is a container or not.
A container is a file which may, upon processing, may generate more input files. The most typical example of a container is an archive, like a zip or a rar file, but many other file types can be containers too: a mailbox, an office document, an executable, etc. Every time libclamav processes an input file which is a container, more input files are generated and scanned. These newly generated "child" files can be in turn containers (e.g. a zip file containing an office document) so the process repeats and child containers are processed and scanned recursively.
It is clear that this process cannot be indefinitely long and, to avoid DoS conditions, an arbitrary end needs to be enforced. That's where limits kick in.
The new limits are based on a distinction, between the main input file, i.e. the original file for which a scan request to libclamav is generated and the "child" input files which are generated as by processing the main input file and its children.
To make it clear let's say we have "archive.zip" which contains 2 files:
"readme.txt" and "setup.exe" where "readme.txt" is a plain text file and
"setup.exe" is a Rar self extracting archive which in turn contains
"myapp.exe", a plain executable, and "license.txt", again a plaintext file.
When a scan request for "archive.zip" is generated (e.g. via clamscan
archive.zip) we have:
- the main input file: archive.zip
Now to the limits:
- MaxFileSize (--max-filesize in clamscan)
This applies to all input files, both the main input and the eventual child input files. It also applies to container and non-container files. This option defines a filesize; input files exceeding it will either be entirely skipped or scanned only up to this value, depending on the file type.
Please note that the following config options are no longer supported:
- MailMaxRecursion - mail files are now treated as containers just like
- ArchiveMaxFileSize, ArchiveMaxRecursion, ArchiveMaxFiles - archives
are treated as containers.
- ArchiveMaxCompressionRatio - the concept of Oversized.* has been
- ArchiveBlockMax - the concept of Oversized.* has been dropped completely.
- MaxFileSize - 25MB
Today, no malicious file is probably larger than 5-10MB, however the overhead introduced by certain container files can heavily affect the final size. The default value should be suitable for most environments. Do not tweak this option by more than 20-25%.