Message-ID: <EA7C77F97CC73F4AAC856A4595DF34E2032B54CA@swilnts801.wil.fusa.com>
From: Glenn_Everhart at bankone.com (Glenn_Everhart@...kone.com)
Subject: Backdoor not recognized by Kaspersky

Technology that would simply mark unknown code and prevent it from
accessing any but a minimal set of resources (and whose markings
normally were inherited by anything written to...this is the old
"integrity" model in many ways...) could largely eliminate problems.

The solidity of the underlying system needs to be at adequate level
though. That is, whatever system functions are included in the "minimal"
set need not to have exploits that will allow a program running in
such a gaol to break out and cause unwanted effects elsewhere. Also
of course it must be necessary for anything such a program does to use
a system call to get out of its own exclusive space. 

Proper usability would suggest further that reports be available about
what the program tried to do. If the presence of the gaol could be
concealed from the program, making it believe it had full system access
for example, that kind of reporting might be more useful. Before it
became so common for most machines to be logged in as administrator,
worms or trojans tended to behave themselves until they saw they were in
a privileged environment.

TCPA seems to be more about keeping control of a person's hardware away from
that person. Interesting admission, that the entire OS layer is chucked
as unreliable, but a new hardware layer is not needed to deal with
mobile code, so much as some tagging and some tracking, so that it isn't
necessary, in running a piece of code, to trust your entire system with it.

Some behavior would need to change too since software suppliers would
really need to be willing to tell people what their code would do and
people need to ask about code that starts doing things not claimed. I am
perhaps optimistic in believing this could be widely arranged by making
default behavior out of the box to be secure...



-----Original Message-----
From: Simbabque [mailto:simbabque@....de]
Sent: Wednesday, March 03, 2004 12:45 PM
To: full-disclosure@...ts.netsys.com
Subject: Re[2]: [Full-Disclosure] 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

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


**********************************************************************
This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you
**********************************************************************

Powered by blists - more mailing lists