[cap-talk] Mac exploit a confused deputy attack

[Karp, Alan H]

Jim Dennis wrote:
> 
>  It is an issue of both ambient authority (anything I run is 
> running "as  me" regardless of where it came from and whether 
> it should be  trustworthy).  We have almost no way in current 
> tools of managing  policies about executable trust.  The best 
> I've ever been able to come  up with for myself on a personal 
> level is a sort of dual UID restricted  shell environment ... 
> where my mail reading, web browsing account is  restricted 
> and my home directory account has to be separately invoked  
> to migrate data into the restricted space (for outgoing 
> attachments) or  therefrom (for incoming).  Even that's 
> pretty weak ... so I need to  have separate sub accounts 
> which have access to different, more  privileged, online 
> resources (such as a different account for each  bank, 
> broker, and retail business establishment with which I intend 
> to  do online business).
> 
You've just described Polaris, except that we automate the process of
adding authority to your restricted account.  Maybe we should make a Mac
version.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp
  

> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org 
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Jim Dennis
> Sent: Saturday, March 18, 2006 9:54 AM
> To: General discussions concerning capability systems.
> Subject: Re: [cap-talk] Mac exploit a confused deputy attack
> 
> On Sat, Mar 04, 2006 at 07:44:14PM -0800, David Mercer wrote:
> > On 2/28/06, Chris Hibbert <chris at pancrit.org> wrote:
> >> The end result is that an application (Safari, the browser) can 
> >> decide that a file is safe to open, since it's only data 
> (jpg, etc.) 
> >> but once passed to the open() call, it turns out that a different 
> >> application is used to open it, for instance Terminal, 
> which treats 
> >> it as a shell script.  In that case, Safari was confused, but the 
> >> user can also be confused by a file that appears to be a 
> jpg or pdf, 
> >> but is an arbitrary executable when opened.
>  
> > This reminds me of a unix trojan in the late 80s.  It replaced a 
> > binary executable owned by a user with a shell script that 
> was padded 
> > out to the length of the original that it replaced with whitespace.
>  
> > -David Mercer
>  
>  That's really not the same.  A simple trojan is in a 
> different category  than a system that hands "data" off to a 
> high level handler/dispatcher  which then "executes it."
> 
>  When I read this it struck me how it's almost exactly like 
> MS Windows  ... where things that look like sound files or 
> images are handed off  to some sort of uncontained, 
> non-validating "open/execute" dispatcher  which then, in a 
> blindly misguided effort to be "user friendly," finds  out 
> what executable to which it whould be passed.
> 
>  (Ooops, that's not a sound, it's a PIF or a .SCR or a VB 
> script ---  we'll just do what the "user" meant because he or 
> she is obviously too  stupid to be have made any informed 
> decision of how this file was named).
> 
>  It's clear to me that these bugs are from an absolute lack 
> of  containment for browsers and MUAs in particular ... and 
> for data exchange  resources in general.  (The issues with 
> PDF handling over CUPS and  other printing systems are a 
> recent UNIX/Linux case in point ... and  filesharing 
> protocols such as NFS, and SMB have have weaknesses that  are 
> every bit as bad.
> 
>  It is an issue of both ambient authority (anything I run is 
> running "as  me" regardless of where it came from and whether 
> it should be  trustworthy).  We have almost no way in current 
> tools of managing  policies about executable trust.  The best 
> I've ever been able to come  up with for myself on a personal 
> level is a sort of dual UID restricted  shell environment ... 
> where my mail reading, web browsing account is  restricted 
> and my home directory account has to be separately invoked  
> to migrate data into the restricted space (for outgoing 
> attachments) or  therefrom (for incoming).  Even that's 
> pretty weak ... so I need to  have separate sub accounts 
> which have access to different, more  privileged, online 
> resources (such as a different account for each  bank, 
> broker, and retail business establishment with which I intend 
> to  do online business).
> 
>  The browser and the MUA have become the ultimate confused 
> deputies  in our personal lives. (At a minimum they should 
> pass data to a  type validation dispatcher that really 
> understands MIME types and  refuses to "play" anything that 
> isn't "sounds, videos, pictures" ...
>  or other "media" (okay --- let's not even discuss what sorts 
> of  "media" could be attached other than audio-visuals).  
>  
>  I personally also think that MUAs and browsers should be 
> contained  (in something at the very least like a chroot for 
> the filesystem  and some sort of constrained windowing 
> decoration for their displays).
> 
>  My browser should not be able to access my financial records 
>  (forgetting the issue of my online, browser accessed Paypal 
> and bank  accounts for the moment) ... and it sure as heck 
> shouldn't be able to  write things into my ~/bin nor open up 
> a dialog that isn't be glaringly  distinguished from any 
> system generated prompts or windows (think  screen savers or 
> MS Windows "shares" access dialogs).
> 
>  For now I'll stay a Luddite and stick with a "crippled" text 
> mode  mail client (mutt) ... but even as much as a curses 
> curmudgeon as  I've been I've been seduced by the GUI side 
> for browsing.  I still  use links/lynx or w3m
> 
> --
> Jim Dennis
> 
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Karp, Alan H.vcf
Type: text/x-vcard
Size: 423 bytes
Desc: Karp, Alan H.vcf
Url : http://eros.cs.jhu.edu/pipermail/cap-talk/attachments/20060320/13b5b031/KarpAlanH.vcf