Recursive archive attachment expansion and filetype/name checks

[Harris S]

Hello, Julian!,

First of all, let me apologise for not getting back earlier on, but
going live with a brand new platfrom (OpenBSD 3.8, MS 4.52.2 - managed
by daemontools, djbDNS, SPamassassin 3.0.4-OBSDpkg, ClamAV
0.88.1-OBSDpkg) is always something that needs planning and attention
to detail prior to and especially after the first few moments of
deployment to live. Been busy to say the least...

First indications are good. Flawless operation and good performance!

A couple of observations though

a) During the first few messages, every child uses considerable
processing power (~60-65% on P4 Xeon 3.06Mhz) which subsequently calms
down and works like a charm with minimum processor usage. I suppose it
is a result of runtime compilation of perl modules which then stay
cached for the lifetime of the child process (???).

b) On OpenBSD with the OpenBSD 3.8 ClamAV 0.88.1 "package", the
clamavmodule did not compile/execute despite my efforts. I will have
to check it out later on. I am currently running with just clamav and
I have to admit that it is heavy on the processors and slow in
invocation. Has anybody succeeded with a similar config?

I will try and publish a guide for OpenBSD as I have not seen one
lying around...

Back to your replies though...

Glad to hear there is a new version out but unfortunately did not have
time to switch and test.

Otherwise, I submitted the alterations I did, for you to have a look,
just in case I was doing something insane! I know that the code has a
number of "issues" (e.g. forced decompressed filename to avoid
sanitisation) and by no means it compares to the elegant and careful
approach which you seem to adopt (e.g. cleaning up potentially doggy
filenames :-) )

However, although I do respect your comments about "popularity" of
exploits, I have to admit that when you look at it from a policy point
of view, statistics sometimes are not relevant.

In the environment I work, we are opting to enforce policies that are
designed to address existing and future vectors of attack. It has paid
off many times.
Frequently commercial programs cannot satisfy this kind of logic either :-).

All in all, Excellent work!

Regards,

Haris

P.S> I believe that the last of the filename rules in
"filename.rules.conf", designed to catch double extensions needs a
fix. It should read "...\s+.." as opposed to "...\s*..." which in
error intercepts files with double extensions like
MyWordDocument.XYZ.doc - where XYZ is a version number....