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: <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