[unisog] MacIntosh Safari Scripts - Hype or Hack?

Stasiniewicz, Adam stasinia at msoe.edu
Tue Feb 21 13:33:24 GMT 2006


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



More information about the unisog mailing list