Message-ID: <404C2DB9.474.1685C0DA@localhost>
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: [inbox] Re: Re: E-Mail viruses

"Aditya, ALD [Aditya Lalit Deshmukh]" to me:

> > I think the kind of approach Kurt has suggested can only realistically 
> > work in corporate and institutional environments (and with the 
> > occasional well-disciplned individual), where it would also be 
> > realtively easy to further restrict the odds of sustaining damage via 
> > this entry route by only allowing designated users to receive such 
> > content.  Further restrictions, such as "it must have the '.ABC' 
> > extension and internally be a RAR archive" could easily be added for 
> 
> this would not greatly add to security ...

I guess that depends how you define "greatly".  This approach would 
greatly reduce the risk from self-replicating code, while leaving a 
reasonably manageable option for trusted employees to get stuff in (and 
out).  However, note it is premissed on the assumption that your staff 
(or at least those allowed to use this mechanism if you restrict it to 
just some Email addresses) are largely trustworthy and careful with 
"new" code (always run it in a test environment making careful checks 
as to what it does, only accept code from certain trusted partners, 
developers, etc).  Of course, if this assumption does not hold and your 
own users pose a significant a threat (they are hell-bent on 
"smuggling" any old cr*p they can get their hands on past your 
defensive measures) then little will help, short of extremely draconian 
restrictions backed up with HR measures such as formal warnings and 
dismissals.

> ... but it would be addeded layer.  ....

And a pretty effective one _for its stated purpose_ if used 
thoughtfully.  Curt did not present it as if it was an absolute 
protection against all evil code, though that's they way many seem to 
have read his initial message...

> ... all
> the archives have a magic header that will allow them to be scanned and
> identified, this is how it works on unix. maybe some thing of that sort is
> required....

Are you trying to teach your grandmother to suck eggs??

> even then how would it solve the prob of encrypted attachments. most
> archirve formats have an options where the file names are visible but some
> like rar have a option to encrypt file name also ie you cannot see the
> names of the files in the archive untill you have the password..

Curt did not say it _would_ solve that problem.  He said it was a very 
effective way to allow your users to receive stuff "they need to 
receive" while stopping scads and scads of the self-mailing cr*p out 
there.  Thus, it solves the encrypted attachment problem as effectively 
as it solves the non-encrypted attachment problem and the non-archived 
attacgment problem and so on.  You seem to have already forgotten that 
Curt's suggestion requires whatever is sending the encrypted attachment 
to correctly guess the arbitrary extension he has chosen _AND_ that 
that is the full extent of the "protection" offerred by this technique.

If you extend it as I suggested, requiring that attachments not only 
have some specific, odd, extension but also be some identifiable 
archive type, you obviously have to have some form of content 
inspection mechanism to enforce that policy.  If the mechanism you use 
is sophisticated enough, you could easily add a rule such as "must be a 
RAR [whatever] archive that does not contain any encrypted content".

Why is thinking this through so difficult for folk??


Regards,

Nick FitzGerald

Powered by blists - more mailing lists