BugTraq
Re: base64 Sep 25 2003 01:06PM
MightyE (trash mightye org) (1 replies)
Re: base64 Sep 25 2003 03:30PM
Bennett Todd (bet rahul net) (3 replies)
Re: base64 Sep 25 2003 11:46PM
Earl Hood (earl earlhood com) (2 replies)
Re[2]: base64 Sep 26 2003 06:02PM
3APA3A (3APA3A SECURITY NNOV RU)
Re: base64 Sep 26 2003 05:08PM
Bennett Todd (bet rahul net)
RE: base64 Sep 25 2003 08:20PM
Alun Jones (alun texis com) (1 replies)
Re: base64 Sep 26 2003 06:11PM
Bennett Todd (bet rahul net)
Re: base64 Sep 25 2003 06:21PM
MightyE (trash mightye org)
This is a remarkably good and simple approach (thus I'm a bit abashed
that I didn't think of it), and permits liberal acceptance, with out
exposing the user to a targeted intentional malformation of base64
encoded data. Accept all mis formed data, make a best guest as to what
it is (or follow RFC on how to handle this where applicable), check the
result, and pending acceptance, write it to the user's mail file, in its
newly interpreted form.

Eric Stevens
mightye a@t mightye d.o.t org

Bennett Todd wrote:

>2003-09-25T09:06:58 MightyE:
>
>
>>There are two methods which you can use in the writing of your
>>email virus scanner; you can either decode it every known way that
>>any client does so, [...] Alternatively you can accept it only if
>>it is properly encoded, [...]
>>
>>
>
>There's a third method, which I think is rather better than either
>of those.
>
>You can re-code everything into a canonical form. Some email client
>drop some punctuation characters in filenames? Delete all such
>characters from filenames. Different tools handle various i18n
>encoded filenames differently? Map to US-ASCII. Enforce length
>limits. Recode base64. Recode uuencoded chunks. Regularize
>non-standard MIME.
>
>Do all this canonicalization before the message hits your
>attachment type policy enforcement and malware scanner, so they only
>have to deal with the common forms that everybody handles the same.
>
>-Bennett
>
>

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus