Someone Else

The Safari / ZIP file exploit in OS X.

I'm actually quite glad I had the chance to wait, reflect and of course drink in other peoples thoughts before starting my own write-up. What looked this morning like a moderately interesting hiccup in Safari now looks like it might chain a minor issue with Safari on to a minor quirk in how the OS itself handles files, to generate what could possibly turn out to be a real issue.

Heise Security provided the original writeup of this issue, and their site is well worth reading if you're interested. The problem is now also being tracked by SANS, who now agree with me that the problem has more depth to it than it first appeared.

Executive Summary.

In my opinion, Apple need to correct the following issues:

1. Safari should not automatically open ANY content.
2. The content in ZIP files shouldn't be automatically opened.
3. Resource fork file information should be compared to other file information when a file is re-assembled and an error called if it fails at least a basic sanity check.
4. A safer default should be chosen for all shell scripts - badly formed shebang lines should be a blocking issue when running shell scripts automatically.

Some background

As many Mac users will know, Apple's file systems break down a file into two "forks". A data fork containing the actual data in the file and a resource fork containing metadata such as icon thumbnails, other information about the file, and most important of all information that the OS uses in determining how to open the file.

This information exists side by side on the file system and overall works in a very similar way to streams in NTFS.

When stored on a non Apple HFS / HFS + disk, OS X will break down the streams into the data fork, which is saved as the "normal file" and another special file containing the data from the resource fork. Such files are named as ._filename, so for example if I save a jpeg file named "photograph" on my Mac and then move it over the network to my windows machine it will result in two files stored on the windows machine - "photograph" and "._photograph".

Prefixing a filename with "." instructs the OS to make this file a hidden file, so Mac users would never see the resource fork file. OS X, of course, sees all and understands how to combine a data file and the resource file to generate all the information on a file that the OS and applications might need.

So what happens with this Safari / ZIP file exploit?

Starting with the ZIP file:

In OS X 10.3, Apple added a feature to create a ZIP file archive of any file from directly within the OS, similar to the Windows XP archive folders feature. To ensure compatability and to keep things tidy for people on other systems who open these archives, the resource fork file is placed into a folder named __MACOSX (that's two underscore _ characters).

So if I create "Robert's Resume.doc" on my Mac, and zip it up and send it to myself on my Windows machine, I will open the zip file to see something like this:

\Robert's Resume.doc
\__MACOSX
\__MACOSX\._Robert's Resume.doc

Windows ignores the contents of the __MACOSX folder, and when we move back to a Mac again, the Mac knows how to combine both files automatically, without bothering the user.

So what if we were to create a "malicious" pair of files, with a data file that misrepresents itself as innocent data, such as a jpeg file, or a QuickTime movie, while actually containing some malicious code, and paired it with a resource fork file that instructed the OS to open the data file as a shell script?

This is what we've got here.

Opening up the "proof of concept" zip file, we find a file named "Mac-TV-Stream.mov" and a folder named "__MACOSX". In the "__MACOSX" folder we find a file named "._Mac-TV-Stream.mov". [screenshot]

If we open the \Mac-TV-Stream.mov file in a text editor we find the following [screenshot]:
# /bin/bash
while true; do
     echo "Hallo Welt!"
done

If we open the "\__MACOSX\._Mac-TV-Stream.mov" file we see a binary file, which contains the following [screenshot]:
%/Applications/Utilities/Terminal.app

So we can see what happens here. We have a file whose extension and icon suggests it should open with QuickTime[screenshot], but this is over-ridden by the resource fork which directs the terminal application to open the file[screenshot] - which just happens to be a shell script instead of a film.

Lastly, the shell script contains a poorly formed Shebang line which ensures that OS X will send it directly to the default handler app for shell scripts - which by default of course is the terminal.

Lessons learnt - When assembling a file from resource and data fork files, OS X should warn the user when the default action suggested from the resource fork is different from that suggested by other file characteristics, and possibly set permissions on such files as non executable when such a mismatch exists.

Moving onto Safari

Safari has an option to open "safe" (their quotes) files after downloading. This is turned on by default, and allows a user to download a file, and if it is "safe" it will be opened automatically.

In the case of archives, this appears to include re-assembling a file from its data and resource files and then performing whatever the resource fork suggests is the default action.

There really isn't much to analyse about this part of the problem - Safari is doing what it is told by design. Arguably the design is rather poor but from a programmers perspective this part of the system is in no way broken.

I'd certainly suggest that this is an unsafe choice of default settings however!

Lessons learnt - Are ZIP files safe to be opened automatically after download? Are ANY files safe these days? This option should be off by default. This is something you can do on your Mac right now, from Safari properties [screenshot]

When an archive is opened, especially if it is by another app such as a web browser, files should NEVER be automatically executed.

Threats from this "attack".

The current "Proof of Concept" script runs a simple "Hello World" statement. This "exploit" runs a shell script in the currently logged in user context, which is analogous to a windows user running a batch file; it can do whatever the user can do and no more. Hopefully you don't run as an administrator - this is actually pretty uncommon on a Mac so this isn't as bad as it could have been.

Of course being able to run as the user is perfectly ample for a script to trash that user's data. We could also install a Trojan into their account, providing that Trojan doesn't require admin rights to install its hooks (see companion virus).

Maybe this exploit can't compromise the underlying OS from a normal user account, but then it doesn't have to affect the OS to break lots of hearts.