Re: [Full-disclosure] mac trojan in-the-wild -- antair restored

[gjgowey@xxxxxxxxx]

Apologies for the cut off posting (antair did it), but I have a few ideas that 
I've yet to see mentioned anywhere.  Maybe they exist already under a different 
name, but here's my two cents in how to fix this mess.

My approach is through the implementation of multiple mechanisms in the os.

1) any file (executable, library, registry entry) that needs to be overwritten 
for an upgrade should be done in such a manner that the original is recoverable 
(ala subversion/cvs recoverability).  This should be monitored and enforced by 
the os.  Windows sort of gets this right with system restore, but there's no 
advanced menu to allow for a more granular selection of what's to be restored 
and that's problematic at best.

2) each program should be executed in separate environments that have roll back 
and security capabilities not just disposability.  This is sort of an extension 
of what sandboxie does and then some.  By security capabilities I mean 
preventing being able to fine tune the read/write access to certain directories 
so that if I want to wall off certain directories in my documents from say ie 
then I can do so.  Currently sandboxie does not offer any granular security 
controls just disposability.

The roll back feature would be to allow modifications to occur in each 
segregated environment, but have the capability to roll back changes of an 
individual environment without requiring a full system rollback.  This would 
allow a damaged environment to be restored without disturbing the whole system. 
 

Obviously I have drawn on sandboxie heavily here and for good reason.  Neither 
chroot, selinux nor anything else that I've seen allow applications to run in 
the native environment with access to the native executesbles and other files, 
but puts up a transparent barrier between the running program and actually 
modifying pre-existing files.  Ideally, the operating system its self should 
have all the above features.

The strategy du jour seems to be that users should have a good back up strategy 
and be prepared to completely reinstall when something breaks which simply 
isn't feasible for the majority of the population of computer users.  Isn't it 
time that we have an os that takes a different approach to read/write access, 
security, and backing up?  Total unmitigated read/write access where one rogue 
program can sink a whole system or send your confidential information all over 
the internet is the real problem.  The current security model of access 
controls is simply inadequate for todays dynamic environment.

The problem with the security model that presently exists is that it stems from 
the unix era when programs were not loaded on by the tonage and what was loaded 
on didn't change often.  All that was of concern was what data the users could 
access with the pre-loaded programs on the system. With todays systems it 
simply is not like that anymore as todays home user is not the grizzled systems 
administrator of old.  Time for a new approach that melds recoverability with 
security is what I say.

Geoff 


Sent via BlackBerry from T-Mobile

-----Original Message-----
From: gjgowey@xxxxxxxxx

Date: Fri, 2 Nov 2007 20:24:45 
Subject: re: mac trojan in-the-wild -- antair restored


That's an interesting figure (86% that is).  Can you give us some
insight into what you define as "user interaction"?

If it is clicking a link or reading an HTML email, then OK.  If it is
opening an .exe from an email, I'd like to see what client you are
talking about and what environment (meaning, what OS/email client and
what did they have to do to get it to run).  But specifically, how many
were exploits where a user had to visit an untrusted site, download an
executable, run it, and explicitly give it administrative credentials to
run?  Not just people running as administrator, but typing in the admin
account credentials to run it as administrator as one has to do on OSX?
My guess (and I'd really like to see details on your findings) is that
most "interactive" issues are the more "trivial" interactive issues
(like clicking a link and launching a vulnerable version of IE). 

But more importantly, let's look at things from the other side.  Let's
say I'm wrong, and that Gadi is right on target with his "hit hard"
prediction and that we should be very concerned with this.  Given the
requirements here, that again being flagrant ignorance where all the
above steps are executed (including the explicit admin part)-- what
exactly are we supposed to do?  If people are willing and able to go
through the motions above what can we as security people do to prevent
it?  Far too many people in this industry are far too quick to point out
how desperate the situatio
Sent via BlackBerry from T-Mobile
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/