Message-ID: <1871733680-1194038406-cardhu_decombobulator_blackberry.rim.net-1276518612-@bxe006.bisx.prod.on.blackberry>
Date: Fri, 2 Nov 2007 21:20:02 +0000
From: gjgowey@...il.com
To: "thor@...merofgod.com" <thor@...merofgod.com>,
	"Bugtraq mailing list" <bugtraq@...urityfocus.com>,
	"Full Disclosure" <full-disclosure@...ts.grok.org.uk>
Subject: Re: mac trojan in-the-wild -- antair restored

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@...il.com

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/

Powered by blists - more mailing lists