Apple Software for the Enterprise

Rixstep
	`About \| ACP \| Buy \| Industry Watch \| Learning Curve \| News \| Search \| Test`

Home » Industry Watch

Seeing Double

It's been going on for twenty two years. The jump to Unix changed nothing. Welcome to Apple Computer.

Just when OS X users started to relax, having worked hard to convince themselves Oompa Loompa didn't represent a tangible threat, they got hit again - and this time even the staunchest believers are scared.

There's a new exploit, on its way into the wild, that requires no user cooperation whatsoever, and therefore gets the highest possible security rating.

Posted by Heise Security, this hole is being given the most severe rating because it requires no user interaction whatsoever. In the worst possible scenario simply visiting a rogue site can result in one's entire home area being wiped out.

Heise have a proof of concept download available here. It's a walloping 682 byte download. The most dangerous situation is when Safari is being used to visit a rogue site and is set to automatically 'open' 'safe' downloads. Something that can be turned off (and should be turned off) rather easily.

defaults write com.apple.Safari AutoOpenSafeDownloads -bool NO
defaults write /Library/Preferences/com.apple.Safari AutoOpenSafeDownloads -bool NO

The hole is also dependent on a flawed interpretation of downloads - an assumption that all shell scripts have the so-called 'shebang row'.

#! /bin/sh

But if Safari doesn't find this 'shebang row' its ordinary caution is thrown to the wind and the download gets 'opened'.

Enter aspect two of the scenario: ever since creator codes and file types it's been possible to arbitrarily assign relationships to document files. Most often in resource forks, and by triggering a Finder flag for the file. Like Oompa Loompa before it, this hole wants to display an innocuous icon in order to fool the user.

Once the user is fooled (if Safari opens downloads automatically there's no wait) the data in the 'resource fork' part of the download takes over, assigning an absolute path for execution of the file.

/Applications/Utilities/Terminal.app

The Shock Doesn't Stop There

The Heise download will appear as a JPEG file in Finder. It's not, but Finder doesn't care. It will look like an image file.

Closer inspection will reveal that the mode of the file is '0755' - which admittedly is strange for a document file; however people do get modes all mixed up all the time, and this in and of itself is not going to be enough to set off the warning lights.

But the download also contains a so-called 'AppleDouble' file in a directory named '__MACOSX'. The file in this directory has the same name as the main file but is much larger - 1420 bytes. It contains the AppleDouble magic 0x00051607 at the very beginning.

00000000  00 05 16 07 00 02 00 00  00 00 00 00 00 00 00 00  |................|

AppleDouble files date back to 1994 or three years before Redwood City slid into Cupertino and buried the beige box. The RFC can be found here. A good rundown of the internal format can be found here.

AppleDouble files are not resource forks - they contain resource forks. The effect is the same (or worse). Files can be zipped up with Apple's 'BOMarchive' and made to behave any way the author wants on remote machines.

From a security standpoint this is a disaster. And the shock doesn't stop there either: for even if the user turns off automatic opening of 'safe' downloads, OS X users can still get hit, for later releases of Apple Mail will be fooled and automatically 'run' the scripts.

The ramifications are staggering.