full-disclosure - Backdoor not recognized by Kaspersky

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <15533237421C6E4296CC33A2090B224A0106931D@UTDEVS02.campus.ad.utdallas.edu>
From: pauls at utdallas.edu (Schmehl, Paul L)
Subject: Backdoor not recognized by Kaspersky

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