OSX Security warning

February 21, 2006 8:00 AM

OSX has a security bug that can be triggered simply by visiting a web page in safari There is an example of the exploit here, to see if your machine is affected. You should probably use firefox until a patch is released.
posted by delmoi (64 comments total)

that's kinda cool.
posted by virga at 8:02 AM on February 21, 2006

Actually, if you download it in Firefox, then double click the Zip file in the Finder, you get the same effect.
posted by cillit bang at 8:11 AM on February 21, 2006

well that's surely easier than arriving at the damn /applications/utilities folder with a dysfunctional finder!
posted by clyde at 8:11 AM on February 21, 2006

okay, fine! /applications then!
posted by clyde at 8:13 AM on February 21, 2006

You should probably use firefox until a patch is released.

Or just uncheck "Open safe files after downloading" option in Safari. This will cause the zip files to just be saved to your desktop.

I have to wonder if opening the zip file manually won't result in the same thing happening. if so, this isn't a Safari problem, it's an OSX problem. Any web browser that let's you download files will work, in which case Firefox isn't any better.
posted by doctor_negative at 8:13 AM on February 21, 2006

On preview, what everybody else said :)
posted by doctor_negative at 8:14 AM on February 21, 2006

There is some more details over at Macintouch, this might also effect Mail.app:

Unfortunately they have overlooked that it also works with Apple's Mail.app. I send you an attached shell script which maskerades as a jpeg image. [...] I think you can easily see the potential harm this could do if slightly changed. Please instruct your users to rename the Terminal application or to move it to a different place, as this seems to be the only measure that can protect users for the moment (against the Safari and the Mail problem).

posted by chunking express at 8:17 AM on February 21, 2006

Huh. Seems like I could just force quit terminal before it has a chance to do anything, too.
posted by generichuman at 8:18 AM on February 21, 2006

Wow! Glad I use Windows.
posted by caddis at 8:22 AM on February 21, 2006

I'm glad you do, too!
posted by Captaintripps at 8:25 AM on February 21, 2006

I just tried this and it crashed Safari. I'm running 10.4.5, and have "Open safe files..." enabled. Strange.
posted by pmbuko at 8:26 AM on February 21, 2006

worked the second time, though.
posted by pmbuko at 8:27 AM on February 21, 2006

I think I am safe. I don't visit Web pages when in safari. Actually, I've never been to a safari and I rarely if ever visit African web pages at all. So, there.
posted by nkyad at 8:30 AM on February 21, 2006

Huh. Seems like I could just force quit terminal before it has a chance to do anything, too.

Scratch that, I can't move fast enough.
posted by generichuman at 8:31 AM on February 21, 2006

Huh. Seems like I could just force quit terminal before it has a chance to do anything, too.

I think you underestimate the speed of a shell script on modern hardware. Even if you stop "rm -rf ~/*" halfway through, that's still half your shit that's gone.

Arrogance, noun. 1. A type of security flaw. See also: Mac users.
posted by secret about box at 8:32 AM on February 21, 2006

Beaten by mere seconds. :-)
posted by secret about box at 8:32 AM on February 21, 2006

doctor_negative: doubleclicking it in the Finder for me doesn't trigger the script execution.
posted by edd at 8:33 AM on February 21, 2006

doubleclicking it in the Finder for me doesn't trigger the script execution.

Depends how you unzipped it. If you used Stuffit, no. If you used the Finder's/Safari's built-in unzip routines, yes.
posted by cillit bang at 8:42 AM on February 21, 2006

Actually, if you download it in Firefox, then double click the Zip file in the Finder, you get the same effect.

You should also move Terminal out of its default location top prevent the script from executing in Terminal.
posted by effwerd at 8:44 AM on February 21, 2006

Or change the name of Terminal to _Terminal. All you want to do is avoid having Terminal in its default path of /Applications/Utilities/Terminal.app.

This is more important than disabling Safari's Open Safe Files feature (though that is important, too).
posted by effwerd at 8:48 AM on February 21, 2006

Renaming Terminal.app seems like a good short-term fix for this example. However, is Terminal the only danger? Applescript or Automator comes to mind. My guess is that it would be possible to use this trick to do something nasty with them.

How many other applications are there installed by default that can execute potentially damaging code? Java, Perl, Ruby, Python. All of these are on the system, in a base install, and each one can be triggered by this exploit.
posted by veedubya at 8:58 AM on February 21, 2006

Sorry, scratch Java from that list. Java requires a distinct compile step before running.
posted by veedubya at 9:01 AM on February 21, 2006

However, is Terminal the only danger? Applescript or Automator comes to mind.

A compiled AppleScript is not a danger. It would require opening the file and manually executing it. I'm pretty sure an Automator workflow would be the same. An AppleScript application (disguised of course) would be a little riskier.

If I get any free time today (looks doubtful right now), I'm gonna look into this more. Hopefully someone else might know.
posted by effwerd at 9:05 AM on February 21, 2006

All of these are on the system, in a base install, and each one can be triggered by this exploit.

Sure, but just running perl or ruby or python's executable won't do much harm. AFAIK there's no way to actually pass a script to them using this exploit.
posted by kindall at 9:06 AM on February 21, 2006

kindall, the entire point of the exploit is that the payload is a renamed script that is maliciously set to be run by Terminal. Rename a Perl script in the same way, change the 'Open With' to /user/bin/perl (or whatever), and there you go.
posted by veedubya at 9:11 AM on February 21, 2006

Glad I use Ultrix!

|d|i|g|i|t|a|l| 4 life
posted by wakko at 9:15 AM on February 21, 2006

The more I think about this, the more worrying it seems. I'm wondering if there is anything installed on my iMac that can both run a script, and has the sticky bit set.
posted by veedubya at 9:16 AM on February 21, 2006

change the 'Open With' to /user/bin/perl

I don't think you can do that. I'm pretty sure it will only work with GUI applications.
posted by cillit bang at 9:19 AM on February 21, 2006

This is why I surf the internet on an amiga running mosaic.
posted by pembleton at 9:22 AM on February 21, 2006

is there something diff about 10.4 that makes it more vulnerable? (i'm 10.3.9)
posted by amberglow at 9:22 AM on February 21, 2006

Does OSX distinguish between types of executable? I didn't know that. Not saying you're wrong, I just never had cause to find out.

Also, I can't believe that I spelled 'usr' wrong.
posted by veedubya at 9:23 AM on February 21, 2006

Or change the name of Terminal to _Terminal. All you want to do is avoid having Terminal in its default path of /Applications/Utilities/Terminal.app.

This is not even close to a way to stay safe. Don't fool yourself.

-------

#!/bin/sh

ls=/bin/ls

for app in `$ls -d "/Applications/Utilities/"*.app`
do
if [ -f "$app/Contents/MacOS/Terminal" ]
then
echo "$app"
fi
done
posted by secret about box at 9:23 AM on February 21, 2006

amberglow, my guess is that the vulnerability would stem from (re-)intriduction of metadata. That was midway through 10.3, I think.

It's that darned BeOS dude. It's always the BeOS dudes.
posted by veedubya at 9:25 AM on February 21, 2006

Good discussion/link to the Heise article, as well:

http://forums.macosxhints.com/showthread.php?s=&threadid=51854
posted by secret about box at 9:30 AM on February 21, 2006

Mikey, you've written a script for finding the Terminal in order to run the script. Well done.
posted by cillit bang at 9:33 AM on February 21, 2006

That's very true Mikey-San. It's basically to defeat what is provided in the example, which is why the primary suggestion is to move Terminal. And even that isn't safe since an AppleScript can find the app.
posted by effwerd at 9:33 AM on February 21, 2006

effwerd, with this exploit you have no way to execute an Applescript (or a shell script) until after you've found the Terminal.
posted by cillit bang at 9:38 AM on February 21, 2006

change the 'Open With' to /user/bin/perl

Nope, won't work.

-Does OSX distinguish between types of executable?

Well, sort of. It's just that only executables that link the Cocoa or Carbon frameworks can accept the Apple events that the OS uses to tell programs to open files. Unix shell executables (e.g. perl, ruby, python) don't link these frameworks, so they won't receive these events. Also, they don't have the resources that tell Launch Services what types of files they can open to begin with, so Launch Services doesn't have them in its database, although it will open them if you specifically request it. Even if you manually edited the 'usro' resource to point to /usr/bin/perl, in other words, it wouldn't actually open the script in perl because perl doesn't understand Apple events.
posted by kindall at 9:39 AM on February 21, 2006

um, hate to bust the paranoia bubble here, but it didn't work for my system (10.4.5). No shell execution of script code. Nothing. Went to the Secunia site, downloaded the test zip file. Which just went to my downloads folder. Tried unzipping the file from the terminal first, to see what would happen. Not a thing. Unzipped just fine to a .mov file. Tried opening it by double clicking in Finder. Unzipped, but still no opening of any processes. Looked at the file in the Finder. Still nothing. Opened the file with Quicktime (since it is a .mov file). Nothing.

I don't see what the deal is. Maybe I'm just farting in the wrong thread.
posted by daq at 9:39 AM on February 21, 2006

The sky is falling. Those sexy kids with their superior computers are dooooooooooooooooomed!

DOOOOOOOOOOOOOOOOOOOOOOOOOMED!
posted by basicchannel at 9:43 AM on February 21, 2006

amberglow, my guess is that the vulnerability would stem from (re-)intriduction of metadata. That was midway through 10.3, I think.

HFS metadata has never been absent from any publicly released version of Mac OS X.

This exploit is triggered by the absence of type/creator metadata so that the extension becomes the primary means of identifying the type of the file, a filename extension that convinces Safari that the file is "safe," and a 'usro' resource that overrides the extension to make the file open in Terminal. (A resource is not metadata, it is in fact part of the file's data, just an alternate stream.)
posted by kindall at 9:43 AM on February 21, 2006

I was a bit ambiguous:

What I'm saying is that renaming things is rarely a solution. An AppleScript could trigger, some random app, whatever. The method of delivery is rather irrelevant. Exploits 101.

The real solution is to turn off "Open Safe Files After Downloading". There's no such thing as a perfectly safe file.
posted by secret about box at 9:44 AM on February 21, 2006

(In theory, LaunchServices knows where Terminal is, regardless of name, so you're only good until it turns out the location is determinable via LaunchServices.)
posted by secret about box at 9:45 AM on February 21, 2006

kindall, that's interesting. I assumed that Finder and Safari were simply creating another process, basically shelling out along the lines of:

${APPLICATION} ${FILE}
posted by veedubya at 9:49 AM on February 21, 2006

with this exploit you have no way to execute an Applescript (or a shell script) until after you've found the Terminal.

I was thinking of an AS app (bundle).
posted by effwerd at 9:52 AM on February 21, 2006

But, it doesn't look like an AS app would work.
posted by effwerd at 9:56 AM on February 21, 2006

Mikey, read my post above. You're seriously overestimating the tools this gives a hacker to work with. All they can do is open one file in one GUI application that is already on the disk in a known location. Anything more sophisticated is out.

I was thinking of an AS app (bundle).

The app would have to already be on the user's disk in a known location for it to be executed this way.
posted by cillit bang at 9:58 AM on February 21, 2006

assumed that Finder and Safari were simply creating another process, basically shelling out along the lines of:

${APPLICATION} ${FILE}

Nope. In fact, most GUI apps don't don't look at the command line args at all. (Hence the need for a separate "bbedit" command line tool, for example.) The Apple events thing goes back to System 7 and is the basis of AppleScript, so they kept it in Mac OS X.
posted by kindall at 10:08 AM on February 21, 2006

cillit bang, I was thinking of a downloaded AS app with a disguised name and icon. I'm definitely no expert but I actually can't figure out how to eliminate the ".app" but keep ".jpg" in the displayed name, despite setting Hide Extension on. And I don't think there's a way to automatically execute the app after download even if I could do the above. Was just speculating on veedubya's question.
posted by effwerd at 10:14 AM on February 21, 2006

C Bang:

"You don't know what you don't know."

The point of the post is that people are enterprising and clever. New flaws in software are found daily, and it's only ever a matter of time before a workaround for a workaround is found by someone. I failed to be more clear in that respect, and that hurt the point of my post. D'oh.

So far, we really only have stopgaps, other than completely disabling the automatic file execution in $BROWSER's preferences. For the moment, that's the only real solution. There's no telling what other vulnerabilities exist within the browser as it stands in regard to this behaviour.

Disabling this "feature"--I consider it a bug or vulnerability, honestly--is always the first thing anyone should do when launching a browser for the first time.
posted by secret about box at 10:41 AM on February 21, 2006

Wow, so this is what every day feels like for a Windows user. Weird.
posted by GhostintheMachine at 10:52 AM on February 21, 2006

Sure glad I use COBOL!
posted by Devils Rancher at 11:06 AM on February 21, 2006

Wow, so this is what every day feels like for a Windows user. Weird.

No, you just go numb and stop paying attention after a while.
posted by sonofsamiam at 11:11 AM on February 21, 2006

MetaFilter: you just go numb and stop paying attention after a while.
posted by basicchannel at 11:21 AM on February 21, 2006

Wow, so this is what every day feels like for a Windows user. Weird.
posted by GhostintheMachine at 1:52 PM EST on February 21 [!]

Nope. Just install a single protection program and go about your business. The same thing, I suspect, will happen for the Mac. No big deal on either system, particularly if you get the updates that both Apple and MS release.
posted by juiceCake at 11:52 AM on February 21, 2006

Yeah, 'cause no one's ever been compromised after being fully updated and running NAV.

This kind of stuff should always be kept in mind. It has happened, it does happen, and it will continue to happen. Remember that there are three factors for security:

1. Basic user education and understanding and practice of the "default deny" trust level in the user's mindset. "Default permit" is a vulnerability.

2. The time between a vulnerability being exploited in the wild and the vendor or security solutions provider's response. You also must factor in the time it takes you to apply the response, whatever it may be. This is a window of opportunity for malicious code, and the main reason there are so many variants of viruses, worms, and trojans in the Windows world--once there's a response, the window closes for X percentage of users. You'll still get millions of boxes, but now there's a "need", so to speak, for opening a new window.

3. Unknown Factor X™: A direct corollary of #2. Since you never really know what vulnerabilities exist until someone finds them, you can't be certain you're solid. I.e., you don't know what you don't know. Someone will exploit a hole and you won't know because either the vendor or anti-virus company haven't released an update or patch yet, or they don't even know about it themselves (yet). Bang, you're still vulnerable, you simply don't know it.

Does this mean you should always wear aluminium foil on your head when you venture out into the Internets? No, but don't think you're totally safe just because you're running all the latest updates. You're just less vulnerable than you would be without them.

Two cents.
posted by secret about box at 12:40 PM on February 21, 2006

Sure glad I surf the net with Lynx for Fortran!
posted by jmcnally at 12:55 PM on February 21, 2006

cillit bang: Depends how you unzipped it. If you used Stuffit, no. If you used the Finder's/Safari's built-in unzip routines, yes.
I used the Finder, and no.
posted by edd at 1:04 PM on February 21, 2006

Yeah, 'cause no one's ever been compromised after being fully updated and running NAV.

This kind of stuff should always be kept in mind. It has happened, it does happen, and it will continue to happen.

Indeed. No one is suggesting otherwise. Although I'd argue that Norton Anti-Virus is itself malware and best not used.
posted by juiceCake at 2:08 PM on February 21, 2006

I've updated Paranoid Android to handle this class of vulnerability. More info can be found here.

Basically, it's an APE module that'll pop up a dialog if anything tries to open a file using other than the default app. The dialog'll let you continue, or opt to open it using the default app instead, neutralizing the threat.

I think it'll provide enough protection until Apple rolls out the real-deal fix.

P.S. I get a pretty big kick out of seeing "work" stuff on my "fun" metafilter site. :)
posted by smeger at 5:54 PM on February 21, 2006

Nothing happened when I tried the "safe" test (which downloads a file that opens up the calculator app). It downloaded the file, but didn't play it. When I clicked on it (it shows up as a Quicktime file) it tried to open it in Quicktime and then said that it couldn't open it because "it is not a type of file Quicktime understands"

Using firefox 1.07 under mac 10.2.8.

Tried it in Safari 1.03 and get the same result.

So is this FUD, proof of concept or an actual problem? 'Cause I don't see any problems, despite trying to get problems.
posted by Brandon Blatcher at 5:59 PM on February 21, 2006

I wish you the best of luck with the problem. Nobody should have to deal with the things that malicious scum sucking jerkoffs design to mess with other peoples computers.

I will however point out that a lot fewer windows people have come in here making comments about switching OS (not naming any specifics here) than usually show up in any windows security threads.
posted by Megafly at 6:31 PM on February 21, 2006

I wish you the best of luck with the problem. Nobody should have to deal with the things that malicious scum sucking jerkoffs design to mess with other peoples computers.

Indeed. There is usually no focus whatsoever on those who perpetrate the vandalism, or crime, or however one wishes to classify it. Lock your doors, lock your computers unfortunately.

I will however point out that a lot fewer windows people have come in here making comments about switching OS (not naming any specifics here) than usually show up in any windows security threads.

The most vocal of them has been banned. Let's hope this puts an end to that sort of smug nonsense, or greatly reduces it.
posted by juiceCake at 7:19 PM on February 21, 2006

So, as a Windows user, I can feel safer posting here now?
posted by stirfry at 7:21 PM on February 21, 2006