Security Hole in Safari

13 Comments

Open Safe Files After Downloading4null4.de is giving us an English overview of a Safari Security Hole being reported by IT Portal Heise Online.

The security hole hinges on a preference being checked. I’ve yet to figure out whether or not this option is checked in a default installation of Safari. Mine was checked.

Either way, it could be bad, very bad. Until a security fix comes along, go to the Safari Menu, Preferences …, under “General”, uncheck the checkbox that says “Open “safe” files after downloading”.

I tried their proof of concept, and sure enough, a Terminal window opened, with a message indicating i’m vulnerable.

update 2/20: English version of the original article, from the source.

update 2/21: Secunia, Macworld, Slashdot are initiating coverage.

13 Comments

Reagan Dishman

I bought a keytroke recorder later to find out that it won’t record certain things, like passwords after this apple security update thing. Is there any way I can change that, i want my passwords to be recorded

Douglas Cootey

I’ve looked into this and I’m simply amazed that this vulnerability exists at all. It apparently occurs only when a single file is zipped. This has nothing to do with putting a misleading icon on the file or even mislabeling the file.

I’ve put up a simple test to show the process here: http://www.cootey.com/temp/mactest.html

The first test is a shell script that simply reveals hidden files in the Finder. Don’t click on it unless you are familiar with the Terminal. I give the command to reverse the process in the script’s output.

You simply shouldn’t be able to do this to another computer. I could just as easily have curled a keystroke logger into your home directory and set it up with crontab.

To show that this is a flaw in how Safari deals with zip files I also include three other tests. One is a GIF file. The other is a PDF file. And the last is a combo of the two in one archive. For the single files Safari autolaunches them into Preview. For the combo archive Safari simply unarchives them and tosses the original archive into the trash as usual.

This means that not just terminal scripts can be used with this vulnerability. If somebody archived any sort of malware alone by itself in a zip archive, Safari would uncompress the file and happily launch the malware. Simply amazing.

Chris Holland

CountZero: actually not exactly. i’ve been running some tests with Mail.app, and you won’t trigger the zip file to be opened and its payload executed by simply opening an email or previewing an email.

You have to 1) open the email 2) double-click the attachment, at which point Mail.app warns you that “hey, this zip file may contain an application, are you sure you want to do this?”, then you have to 3) click OK, to eventually save it to your desktop. then 4) you have to click on the fake image icon to trigger the script.

And it comes back down to the issue C.B.: mentioned: the core problem is that a shell script is allowed be shown as looking like an image.

Fixing the Safari issue will be a first strong step. The whole file masquerading issue is still an issue but not as bad. The potential infection vector via Safari is far greater than what i just outlined via Mail.appl, or finding the image on your desktop and double-clicking it.

CountZero

you’re not done with disabling that option in Safari. The issue hast extended to the next level, as it is confirmed now that you can achieve the same thing with a prepared email and AppleMail as well. Even if you download a prepared zipfile by accident and open the zip, the issue catches you.
This is REALLY a big issue not to be ignored!

C.B.

Yeah, but the thing is — the Safari flaw has a simple workaround, uncheck the “Open safe files” box. (That box shouldn’t exist in the first place, and maybe Apple will finally just remove the option in a coming update.)

But, to me, the fact that a shell script can look in absolutely every way like any kind of document, and the only way to differentiate it is to display the Get Info window, is a much more serious flaw. And seeing everyone treat this as a security hole in Safari, when the problem is in fact much broader, makes me fear that Apple may overlook that and just go for a quick fix.

Chris Holland

c.b.: yeah, and on top of that, i could also *make* your browser download the nefarious payload behind the scenes upon visiting some seemingly innocuous web site, by making it the SRC attribute of an iframe.

and that could be *bad*.

C.B.

“Why would a screenshot be in a tarball? And why wouldn’t you be worried about the resulting file, if Safari pops up a warning every time you download a file that has executable code inside?”

Why wouldn’t a bunch of jpegs be in a zip file to be downloaded at once?

How many users know that you shouldn’t double-click a jpeg without using Get Info to double-check that it isn’t a Terminal file, even though they configured OS X to show file extensions, and the extension is there alright, and the system’s JPEG icon is there too? (I don’t mean the regular icon — my JPEGs open with Xee, and the heise online proof-of-concept script displays with the Xee icon on my desktop.) I know I didn’t. Have I actually been spoiled by Windows’ security? That would be something.

From what I read, this is different from the latestpics.tgz trojan (the file inside the tgz didn’t have an extension) and from the Intego proof of concept (which used a different mechanism to “infect” the computer). This is about Terminal files being able to masquerade as any other filetype, and the Finder actively helping them at that.

Chris Holland

from the article:

Safari will also unpack ZIP archives and display the documents within if they are considered “safe”. If active content such as an application or shell script is found within the archive, a prompt requests user confirmation. So far, so good.

and then here’s where the flaw lives:

Problems ensue if a shell script is stored into a ZIP archive without the so-called shebang line. If this line is omitted, Safari no longer recognizes the content as potentially dangerous and executes shell commands without a confirmation prompt.

Chris Holland

Jason: because instead of making this a link for you to nicely click and download, i can make that proof of concept URI, the source of a hidden iframe, and cause an arbitrary piece of shell code to execute instantly upon your loading my otherwise seemingly harmless blog.

It is actually new news, and is different from the Dashboard widget.

If the concept of what Safari considers a “safe file” can be corrupted, then we do indeed have a problem. It shouldn’t be too hard to fix. But it’s well worth being aware of.

Jason Terhorst

Old news. This was covered right after Tiger came out. Had to do with the “proof of concept” that Intego developed, which was just their way of trying to scare people into buying their product.

A lot of the stories written related to this were FUD, and the result of people generally doing stupid things. (Why would a screenshot be in a tarball? And why wouldn’t you be worried about the resulting file, if Safari pops up a warning every time you download a file that has executable code inside?)

Come on, people. Think smarter, not harder. This is just FUD.

Asapin

It has something to do with files that look safe to Safari like jpgs that can be dangerous scripts like the recent mac trojan.

Comments are closed.