full-disclosure - [inbox] Re: Re: E-Mail viruses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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

Valdis.Kletnieks@...edu to Curt Purdy:

> > Ah, I wish...  An alternative is to allow only a proprietary extension
> > through, like .inc  Legitimate senders would rename the file, be it .exe
> > .doc .jpg, indicate in the body of the message what the true extension is,
> > and the receiver merely renames it.  A little trouble yes, but it virtually
> > eliminates email propagated viruses from the corporation.
> 
> So let's see.. the same bozos who read the text part of the virus, get
> the password, and use that to unzip the rest of the virus won't read
> the text part, get the rename to do, and..... 

Yes, but to get through to Kurt's users, the malware (or its sender) 
has to guess (or know if it is a directed or insider attack, in which 
case "protection" is fundamentally harder anyway) the "right" 
extension.  Limiting ourselves to three-character-only, non-case 
sensitive ASCII alphanumerics, that is a one in 3^36 chance.  Anything 
else will be stopped as "unwanted", so a virus trying to "fake out" 
this approach still won't get to the users behind a perimeter  
filtering mechanism enforcing this kind of policy...

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 
the even more paranoid, but with today's content scanner options such 
an approach will seriously limit the range of choice as very few such 
products have really been desgned from an intelligently outward looking 
policy enforcement perspective... (they tend to be far too heavily 
focussed on the "we _don't want_ files matching this profile" approach, 
rather than having genuinely inventive "let this kind of content in and 
block the rest" options).

> Color me dubious....

Or a poor reader??   8-)

Regards,

Nick FitzGerald