[unisog] MacIntosh Safari Scripts - Hype or Hack?

Edgecombe, Jason jwedgeco at email.uncc.edu
Tue Feb 21 15:37:49 GMT 2006


FYI, they are moving away from resource forks, but they must support
them for legacy reasons.

Jason Edgecombe
TST Web Developer
Dean's Office, College of Arts & Sciences
UNC-Charlotte
Phone: (704) 687-4686 

 

> -----Original Message-----
> From: unisog-bounces at lists.sans.org 
> [mailto:unisog-bounces at lists.sans.org] On Behalf Of Stasiniewicz, Adam
> Sent: Tuesday, February 21, 2006 8:33 AM
> To: UNIversity Security Operations Group
> Subject: Re: [unisog] MacIntosh Safari Scripts - Hype or Hack?
> 
> Here is a crazy idea.  Why doesn't Mac simply use the following logic:
> -If fork and extension match, proceed normally.
> -If either fork or extension is present, go with what it's got.
> -If for and extension don't match, don't allow any program to 
> open file
> until user changes extension.
> 
> This logic would have to be coded in some low level area for it to be
> effective, but I think it should stop these and similar attacks.
> 
> Also, maybe it is worth mentioning that Mac should consider 
> moving away
> from resource forks completely, since only Mac can read them.
> 
> Regards,
> Adam Stasiniewicz 
> Computer and Communication Services Department 
> Milwaukee School of Engineering 
> MSCE: Messaging & Security 2003 
> 
> > -----Original Message-----
> > From: unisog-bounces at lists.sans.org
> [mailto:unisog-bounces at lists.sans.org]
> > On Behalf Of John Rowan Littell
> > Sent: Tuesday, February 21, 2006 6:57 AM
> > To: UNIversity Security Operations Group
> > Subject: Re: [unisog] MacIntosh Safari Scripts - Hype or Hack?
> > 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > 
> > Lo, Gary Flynn and the teakettle whistled in unison:
> > 
> > [snip]
> > > http://www.heise.de/english/newsticker/news/69862
> > > http://www.incidents.org/
> > >
> > > Obviously, if anyone can put a file on a web site that
> > > will run unix shell scripts if hit by a Safari browser,
> > > this is extremely serious. I keep seeing the word
> > > "automatic" everywhere.
> > >
> > > Yet the heise.de site says,
> > >
> > > "If the user has assigned the Finder to open scripts
> > >  using the Terminal, this will happen automatically."
> > >
> > > That sounds like something needs to be changed from
> > > default. One person I asked said,
> > [snip]
> > 
> > This is the default, actually, so I'm not sure why the heise.de web
> > site phrases it that way.  The scripts in question are not
> > AppleScripts but standard unix shell scripts.  However, the tricky
> > part of this whole thing is that MacOS X is relying on the resource
> > fork of the file to determine what application to open it 
> with -- but
> > only for this attack.
> > 
> > Take the example that heise.de has at the bottom of their page (it's
> > safe -- I downloaded it first without "open 'safe' 
> documents" enabled,
> > which is actually how I prefer to do things anyway).  The ZIP file
> > contains:
> > 
> >  	  76  02-20-06 09:41   Heise.jpg
> >  	   0  02-20-06 09:41   __MACOSX/
> >  	1420  02-20-06 09:41   __MACOSX/._Heise.jpg
> > 
> > Heise.jpg is a shell script file that does '/bin/ls -al' and a few
> > echos.  Because it's got the .jpg extension, Safari and 
> StuffIt think
> > that it's a "safe" document.  However, if you look at the
> > __MACOSX/._Heise.jpg file -- the resource fork stored in a non-HFS
> > compliant manner -- the contents say that
> > /Applications/Utilities/Terminal.app should open the file.  So
> > Safari/StuffIt (I'm not sure which, at this point) send OSX 
> a request
> > to open that file, and OSX looks at the resource fork, fires up
> > Terminal.app, and runs the shell script.
> > 
> > It works.  Turning on the open safe docs option in Safari 
> on my laptop
> > fires up a shell window and tells me the contents of my home
> > directory.  It's running with my standard access rights, 
> and could do
> > anything that I could do.  It's pretty noticeable to have a terminal
> > window suddenly pop up after you download something, but by the time
> > you notice it, the script's already done the dirty work.
> > 
> > The fixes, are, of course, as heise.de says: disable the open safe
> > option in Safari or to (re)move Terminal.app so that malicious ZIPs
> > can't find it.  The longer term fix, though, is building yet another
> > layer of file content identification for OSX: think about it, we've
> > already got file extensions and resource forks.  Both are 
> used to tell
> > OSX what kind of file we've got.  Here, they don't agree, 
> so different
> > parts of OSX learn different things.  Perhaps, instead of looking at
> > metadata to determine the file contents, we should be looking at the
> > contents itself?  I don't know -- there are certainly ways to fool
> > file(1), and as Certain Vendors have shown us, even if you 
> accurately
> > identify a file, it can still contain stuff that will spork your
> > system.
> > 
> >    --rowan
> > 
> > - --
> > John "Rowan" Littell
> > Systems Administrator
> > Earlham College Computing Services
> > http://www.earlham.edu/~littejo/
> > 2006-02-21 07:41
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.4 (Darwin)
> > Comment: http://www.earlham.edu/~littejo/littejo.asc
> > 
> > iQCVAwUBQ/sOMpdUNSJ2nf/5AQEOLgP+PqL2y9ZPw2wMK/oGmRtrVV15BxhzAMqm
> > E8lZAuwhd909YM6GZWcbin2sxraslCZoQSeqWvZ/1Eh5GolTXeM6A7ZMrdEgT+VQ
> > o0kV//N+/BCfzeyDD69KS/y0k/vfXcrgErgHZ7EERhQYfMPKx/9BUkhdg+AtfvrI
> > 73D1Hu09exU=
> > =fcz/
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > unisog mailing list
> > unisog at lists.sans.org
> > http://www.dshield.org/mailman/listinfo/unisog
> 
> _______________________________________________
> unisog mailing list
> unisog at lists.sans.org
> http://www.dshield.org/mailman/listinfo/unisog
> 



More information about the unisog mailing list