Recursive archive attachment expansion and filetype/name checks

[Julian Field]

On 26 Apr 2006, at 22:57, Harris S wrote:

> 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 (???).

I think that's probably it, yes.

> 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!

Thankyou!

> 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....

It is exactly as I intended it.

-- 
Julian Field
www.MailScanner.info
Buy the MailScanner book at www.MailScanner.info/store
PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.