Date: Thu, 25 Sep 2003 09:06:58 -0400
From: MightyE <trash@...htye.org>
To: Lawrence MacIntyre <lpz@...l.gov>
Cc: bugtraq@...urityfocus.com
Subject: Re: base64




Lawrence MacIntyre wrote:

>Whatever happened to the strategy:
>
>Be conservative in what you send and liberal in what you accept.
>
>  
>
This strategy falls on its face when you're looking at scanning emails 
for viruses.  If you're liberal in what you accept, then someone has the 
ability to encode their virus, targeted toward a specific mail program, 
which behaves in a certain way when it encounters improperly encoded 
base64 data. 

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, in which case you are only ever able to perform damage control, 
and must update your software each time a program exhibits new 
behavior.  This method also introduces a high load on the mail server 
since you have to decode the same attachment many times, and scan it for 
viruses many times.  If there are only 5 conceivable means to decode an 
error in the base64 encoding, then you've introduced 5 times the load on 
your mail server compared to traditional approaches.  This thus also 
opens you wider to DoS attacks.

Alternatively you can accept it only if it is properly encoded, relying 
on the 99.9% of clients out there that know how to read an RFC.  If all 
mail servers had always only accepted proper base64 encoding, then the 
authors of all email clients would have their clients encoding correctly 
from the very start, and you'd never need to worry about this now (or 
else they'd never actually get any users since they'd have a hard time 
sending attachments).

>The real problem isn't badly formed MIME attachments or blown BASE64
>encoding, it is instead mail clients that execute email as if it were
>code, when we all know that email is simply data.  You don't execute
>data...
>
>  
>
No, the problem at hand is how best to scan for viruses in incoming 
email, that's what the discussion is centered around.   This latest 
virus going around uses social engineering to get the user to run the 
executable; the mail program never runs it.  In your paragraph above, 
you thus describe this as not a problem, or failing that, this certainly 
doesn't fall within your description of what a problem is.  I disagree, 
and insist that in an increasingly hostile Internet environment, 
stricter acceptance policies are needed more and more.  Non compliance 
with RFC's should not be tolerated, this sort of non compliance is 
specifically the sort of loop hole that crackers can exploit to bypass 
the likes of virus scanners.

>p.s.  If your theory on broken clients were true, then Outlook would be
>gone by now:-)
>
>  
>
No, because my theory depends on being conservative in what you accept; 
being liberal in what you accept does not give users of broken clients 
any incentive to find a functioning client.  When users are hit by an 
Outlook worm, everything blows over in a week or two, it's a big 
inconvenience, but they're again sending emails again, and the problem 
is "fixed" as far as they're concerned, so no reason to change now, they 
after all have their address book set up in this client.  If a worm came 
around that was hitting them, and there never *was* a fix for their 
client, the user is faced with either dropping off the face of the 'net 
for eternity, or finding a new client.  I think we're both aware of what 
the obvious choice is for the user here.

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

>On Wed, 2003-09-24 at 15:13, MightyE wrote:
>  
>
>>I agree, I don't think it's unreasonable to reject improperly formatted 
>>messages.  Chances are much higher that they're spam or virii, and the 
>>minority with broken clients will find their way to non-broken clients.  
>>If you are parsing the message, particularly looking for malware, and 
>>encounter an improper encoding, bounce the message with a meaningful 
>>error, this way you don't have to worry about a targeted exploit that 
>>depends on the way one email client (mis)interprets a message in a 
>>different way from your virus scanner.
>>
>>The RFC does declare an = to indicate that the end of the data stream 
>>has been reached, further data should be truncated, though it seems each 
>>email client actually handles this differently.  Take the low road 
>>catchall, and simply reject them as a matter of course.
>>
>>-Eric Stevens
>>mightye a@t mightye d.o.t org
>>
>>Christian Vogel wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>On Tue, Sep 23, 2003 at 07:50:56PM +0300, Alexander Ogol wrote:
>>> 
>>>
>>>      
>>>
>>>>decision in all situations. Some mailing lists (debian-russian, for example)
>>>>add some 7bit information after letter body while re-forwarding, regardless
>>>>of was the letter base64/QP encoded or not, resulting of such malformed
>>>>   
>>>>
>>>>        
>>>>
>>>Then this software is severly broken (MIME-wise), imho, and needs to be
>>>updated/changed/dumed.
>>>
>>> 
>>>
>>>      
>>>
>>>>So I think that the right solution (before antivirus software would be
>>>>rewritten) is to write filters by yourself - decode base64 as that do
>>>>popular mail clients and give them to antivirus.
>>>>   
>>>>
>>>>        
>>>>
>>>With this approach, you are always on the "one step behind" side of
>>>the problem. It's only a matter of time that someone finds out that
>>>(made up example:) you can use a UTF8-mis-encoded "=" in Microsoft's
>>>base64-decoder... The only sane way is to check if it's in the
>>>standard-form ("abcABC=") and reject or convert if it's not.
>>>
>>>99.99% of all software should create the standard form, so please
>>>let the tiny fraction of users with broken software suffer
>>>when their mails get rejected.
>>>
>>>(Note: this of course applies not only to Base64 but to all aspects
>>>of header-parsing, file-format guessing etc...)
>>>
>>>	Chris
>>>
>>> 
>>>
>>>      
>>>

Powered by blists - more mailing lists