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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ