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: <18210606855.20040303184458@web.de> From: simbabque at web.de (Simbabque) Subject: Backdoor not recognized by Kaspersky > Anti-virus has *always* been an arms race and the anti-virus companies > will never win. I wrote about this almost two years ago for > Securityfocus [1,2]. We need new/different technology that doesn't > depend upon knowledge of the malicious program to prevent it from > entering our networks. *Re*active technology will *always* fail > initially, and that means there will always be a door open for bad > things to happen. Does that mean TCPA or other sorts of "trusted" systems? -- Am 03.03.2004 schrieben Sie / on 03.03.2004 you wrote: > -----Original Message----- > From: full-disclosure-admin@...ts.netsys.com > [mailto:full-disclosure-admin@...ts.netsys.com] On Behalf Of Cael Abal > Sent: Wednesday, March 03, 2004 8:57 AM > To: Gregor Lawatscheck > Cc: full-disclosure@...ts.netsys.com > Subject: Re: [Full-Disclosure] Backdoor not recognized by Kaspersky > > What about messages in languages other than English? I can > easily see > this becoming an arms-race, and one the anti-virus folks have > no chance > of winning. > Anti-virus has *always* been an arms race and the anti-virus companies will never win. I wrote about this almost two years ago for Securityfocus [1,2]. We need new/different technology that doesn't depend upon knowledge of the malicious program to prevent it from entering our networks. *Re*active technology will *always* fail initially, and that means there will always be a door open for bad things to happen. There *is* work ongoing in this area, and I have high hopes for one such solution (but I'm under NDA, so I can't discuss specifics.) > Leave passworded .zips alone -- take the sensible approach > and catch an > infected file once it's been extracted. > That's no longer sensible because it depends upon the end user to do the right thing, i.e. keep their AV software up to date, properly configured and enabled, and we *know* from experience that is a failed remedy. The sensible approach is to no longer accept executable content/attachments in email and to classify zip files as one of those types of executable content. In fact, Nick Fitzgerald has been right along. We should be *white* listing allowable attachments and everything else should be summarily bounced/refused/silently discarded. If I do not accept executable content at my gateway, then I don't *need* to know if it was malicious or not. In fact I don't even care. Email was never designed to be a file transfer mechanism, and we rue the day that some bozo decided that it was. There *are* appropriate file transfer mechanisms available (both encrypted and unencrypted), and we should be using those appropriately. Email should be used for communications *only*, which is what it was designed for. Advertisers can still send their pretty HTML email, but they would only be able to get graphics files through. Scripts and other active content should be disallowed. Paul Schmehl (pauls@...allas.edu) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/~pauls/ [1] http://www.securityfocus.com/infocus/1562 [2] http://www.securityfocus.com/infocus/1604 _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Powered by blists - more mailing lists