Tomasz Kojm wrote:
> On Thu, 04 Oct 2007 00:47:02 +0200
> Karsten Bräckelmann <[EMAIL PROTECTED]> wrote:
>
>> On Wed, 2007-10-03 at 10:45 -0700, Dennis Peterson wrote:
>>> Karsten Bräckelmann wrote:
>> Developers, read on. :)
>>
>>>> Somewhat simplified, the signature reads "Subject with the string game"
>>>> and "an IP style http link".
>>>>
>>>> Scanning maildirs as well as scanning individual messages before
>>>> delivering, this enforces that both be in the same email. Scanning a
>>>> whole mbox however, does *not*.
>>>>
>>>> The Subject can be in one message, and the link in another one further
>>>> down the file. Boom, we got a hit! :) (Actually, according to your
>>>> prose description, it neither needs to be a (Subject) header, nor an IP
>>>> style link.)
>>>>
>>>>
>>>> Which raises the question if the OP is correct when stating that ClamAV
>>>> knows how to handle mbox files. It sure does not look like that. The
>>>> summary claimed to have scanned one (mbox) file. It did not claim to
>>>> have scanned a bunch of messages, treated individually and applying the
>>>> signatures against each of them -- just a single text/plain file, that
>>>> happens to resemble more than one message.
>>>>
>>> This is my conclusion too, and the question was really thrown out there
>>> for comment from the SourceFire folks to provide clarification. Given
>>> that clamscan knows where in the file it is as well as being aware of the
>>> construction of it they appear to be very close to doing the right thing
>>> so it would be surprising to learn they do not.
>> Right. :) Adjusted the Subject accordingly. Maybe this will get some
>> attention by the developers. Would be nice if someone could shed some
>> light on this. Or implement it.
>>
>>
>> Another downside of this approach, together with ClamAV treating mbox
>> format files as text/plain is, that only the first hit will be reported.
>> Something to keep in mind for the use case mentioned in that other
>> thread. All you will gain is knowledge, that the users might have been
>> exposed to some threat, before the good guys caught up. You will *not*
>> know which threat, since there may be others lurking, too...
>
> Hi Karsten,
>
> this is what we currently do for mbox and other special files supported by
> libclamav:
>
> (1) try to extract/unpack/parse/etc. the file and then scan the output data
> (2) if no virus is found in (1) then scan the _raw_ file
>
> There are important reasons to perform (2), for example - if some unpacker
> fails to process an archive (cannot extract all files, etc.) we can always
> release a signature matching the archive itself. This is a 'better safe than
> sorry' approach which already helped us in the past, however it's also
> possible that for too generic signatures it may have some side effects like
> the one described in this thread (matching one sig between different msgs).
>
> HTH,
>
Any chance to set policy that requires the pattern writers anchor the patterns
so
they stay inside a message? I don't if the code can compile something like
this, but
it prevents (on first blush) spanning messages:
^.ubject: (other regex stuff here) * ^From <- space character
This would stop wildcards from spanning messages. Unchecked those wildcard
characters
can create very cpu intensive patterns and it may be they're best not used if
they
cannot be anchored or constrained as with {-50}.
Or start the scan by establishing a record separator (^From ) and pull that
record to
a buffer.
I wouldn't get up from the dinner table to do any of this, but it might belong
on the
ToDo list or FFR.
dp
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
