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: <Pine.LNX.4.21.0403031323350.13045-100000@kcisp2> From: mikehome at kcisp.net (Mike Barushok) Subject: Backdoor not recognized by Kaspersky I feel the need to address the problem from an ISP perspective, since the corporate and government and other institutional persective seems to give different answers. And because the ISP end user problem is still the majority of the reservoir for viruses (and spam proxy/relay/trojans). On Wed, 3 Mar 2004, Schmehl, Paul L wrote: > > -----Original Message----- > > From: full-disclosure-admin@...ts.netsys.com > > 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 > > > > 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. Just to amplify something that may not be obvious in the above. Even if the end users are doing 'the right thing' as described above there are two problems at least. 1) How often to update a virus scanner has changed radically within the last two years or so, and the update mechanisms used by most end users have not kept up. Most users were not terribly unprotected if they checked for updates once per week or even once per month in early 2002 if they left their virus scanners at default update intervals. And even if they got infected, and started propogating an email virus, the viruses they were infected with back then were not as efficient as now. Additionally there are consequences of current viruses, like e.g. being a spam proxy and spewing out hundreds, thousands or more spam messages traceable back to the ip address of the infected machine. Many of the current virus scanners in common use by home users do not allow setting the update interval to multiple times per day, but the frequency of release of new viruses is accelerating to the point that if it were practical, that inteval of updates seems logical. 2) Because of the efficiency of recent SMTP engines in viruses, the interval between a new virus being released, and the typical end user being exposed is much shorter than ever before. Therefore the window of opportunity between the virus propogating and there even being any update available from the anti-virus vendors is much more of an issue than in the past. > 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. For typical home end users on ISP operated mail servers there are major issues with this. End users usually expect that whatever was sent to them is going to be made available to them. Many will not accept a blanket policy that causes them to change how they receive content that they were formerly able to receive as email attachments. If every ISP simultaneously adopted the exact same policy on emailed attachments, and if every end user knew that all ISP's were changing at the same time, then ISP's could force the change, and the end users would have to grudgingly accept that some attachment types could no longer be received in the way they formerly were available. But there is zero consistency in how ISP's are solving this issue currently. Some will make a web based quarantine available, and some will place extra tags in headers and some will change the file extensions and some will just strip the attachment out and some will add a notice within the body of the original email and some will email a separate notice, and so on. But most are aware that any significant change will risk the customers changing to a different ISP. In the past customers were loyal because they did not want to go to all the trouble of informing friends and family of their new email address, but now since instant messaging is independent of the ISP you use, and since email is mostly a hassle, their is not the same loyalty so ISP's are reluctant to make radical changes. > > 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