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
| ||
|
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
Powered by blists - more mailing lists