We received notice from Juergen Schmidt, editor-in-chief at heise.de, that a serious vulnerability has been found in Apple Safari on OS X.  "In its default configuration shell commands are execute[d] simply by visting a web site - no user interaction required."  This could be really bad.  Attackers can run shell scripts on your computer remotely just by visiting a malicious website.

Full text of the article: http://www.heise.de/english/newsticker/news/69862
Proof of concept from the original discoverer (Michael Lehn): http://www.mathematik.uni-ulm.de/~lehn/mac.html

The problem is due to a feature that is activated by default: Open Safe Files after downloading.  A zip file is considered safe and so they will be opened automatically.  Subsequently, a shell script with no #! at the beginning of the script will be executed automatically.  No user interaction!

Recommended action: disable the option "Open 'safe' files after downloading" in the "General" preferences section in Safari.

---

UPDATE

This actually looks more serious then we initially thought it is. The workaround specified above will prevent Safari from automatically executing the PoC file, but it looks like your machine is still vulnerable and it doesn't need Safari to run this file at all.

The article on Heise explains where the problem really is. When this script was stored in a ZIP archive, Mac OS X will add a binary metadata to the archive. This file determines what will be used to open the main file in the archive, regardless of the extension or symbol displayed in the Finder.

This can be easily tested with the ZIP archive from the original discoverer. If you unpack this ZIP archive on a Linux system (I'm not sure if you can see all the files on a Mac as I don't have one near to test this on), you can see that beside the main file (which is just a shell script), there is also a directory called __MACOSX:

$ unzip Mac-TV-Stream.mov.zip
Archive:  Mac-TV-Stream.mov.zip
  inflating: Mac-TV-Stream.mov
     creating: __MACOSX/
     inflating: __MACOSX/._Mac-TV-Stream.mov

The metadata file in this example is ._Mac-TV-Stream.mov. This is some binary file, but even running simple strings command on this file will reveal what the real utility used to open the main file is:

$ strings ._Mac-TV-Stream.mov
%/Applications/Utilities/Terminal.app

It looks like this can be used to fool users into starting the file no matter which vector is used (download from the web, e-mail, or something else).
According to the Heise article, "users should verify that the OS is using the proper file type. This can be done through the information window or in the column view."
You can also move your Terminal application somewhere else, but this might (and will) break other things.

Bojan Zdrnja
Handler on Duty

---

UPDATE 2

Heise published another article about the MAC OS X vulnerability and, unfortunately, it is as bad as we thought it is (even worse).
The original article is at http://www.heise.de/english/newsticker/news/69919.

The article also says that the Mail application is vulnerable as well. What's even worse, the attacker doesn't need to send a ZIP archive; the shell script itself can be disguised to practically anything.

The Finder looks like the main culprit for this. The way it uses to decide what to do with the file and what to show to the end user (as the icon).
The main principle behind this seems, let's say, stupid. For the icon which will be shown to the user, the Finder will use the file extension - so whatever you put as the extension will be *always* used as the icon.
Now comes the interesting part - for the application which is used to open the file, the Finder will "consult" file permissions. In other words, if the file has any of the executable bits set, Terminal.app will be used to open it. Otherwise, the Finder will use application according to the file extension (so, if it's a .gif file, it will use image viewer to open it, but only if there are no executable bits set on the file).

Now back to the e-mail as an attack vector and example from Heise's article. The test e-mail the send has an attachment called Heise.jpg, which is in fact just a shell script.
Content-type for this MIME attachment is multipart/appledouble, which makes Mail parse it.

The important part is this:

Content-Transfer-Encoding: 7bit
Content-Id: <65891ABD-2356-488E-9A2D-3D85BC1DD282@ct.heise.de>
Content-Type: image/jpeg;
        x-mac-type=0;
        x-unix-mode=0755;
        x-mac-creator=0;
        name="Heise.jpg"
Content-Disposition: inline;
        filename=Heise.jpg

As you can see, it is possible to define permissions of the file with the x-unix-mode statement. This will make Mail save this with 0755 permissions and when user double clicks on the attachment (which still has the JPG icon!) it will be automatically executed without any warning.

Luckily, Thunderbird doesn't honor appledouble/applefile MIME extensions so this doesn't work automatically from it - it would be a wise thing to use Thunderbird until this issue is solved.

If you have to use Mail, don't double click to open attachments but save them first, and then go with the Finder to their location - if you have detailed view selected, under "Kind" column you should be able to see what application will be used to open the file.

File permissions depend on umask set - the default one on MAC OS X is 0022. If you change this to 0777 with the umask command, it will stop Mail from automatically opening attachments. Because the file is owned by the user doing the reading, the required umask would break too many things to be a feasible solution.

Last, if you can, strip x-unix-mode from your e-mails on the gateway.

Thanks to our readers for helping us with the analysis.

Bojan Zdrnja
Handler on Duty