A new security issue has apparently been found in Safari. What does it mean? That some features should not exist, regardless of how secure an application is.
According to Heise Online, a security vulnerability has been found in Safari, allowing for the execution of shell scripts under certain conditions, provided the “Open Safe files after downloading” option is checked. Of course, one could argue this is very little of an issue, given any “reasonable” user would uncheck that option first thing upon delivery of his computer.
Yet, that option is enabled by default and, to the average user, clearly states it is innocuous. While alternate browsers such as Camino explain that “Open[ing] downloaded files” could “make your computer vulnerable to damaging programs”, Safari, the browser aimed at the regular consumer, downplays the risks of such a behavior — and, frankly, who would question Apple’s own wording, on its default browser?
So, what is this entry about? Bashing Apple for implementing yet another insecure feature? Not really. Indeed, I believe “Open downloaded files” is actually a nifty trick that makes many complex operations transparent to beginners, especially the installation of legitimate software. In that, I understand and appreciate Apple’s original idea: make things easy, simple and straightforward, maybe even more secure as this forces the browser to run a security check on the files to determine what an archive contains, something your average beginner might not do if he were to open archives in StuffIt with a simple double-click.
Yet, one has to wonder. Internet Explorer is constantly criticized and constantly hacked because of its ability to execute programs automatically. Outlook Express was almost banned from most corporations a while ago for the same reasons. In fact, it seems every time an application accepts executables from the outside world and processes them automatically, someone has found a way to exploit them, no matter how secured, protected, isolated they are made. This in many ways reminds me of horses who, while defeated by the most standard of locks, found on stable doors for centuries, constantly find ways around newfangled mechanisms that include automatic latches and button-press emergency release latches. Anybody banging on a door long enough, softly enough and with enough perseverance will be able to cheat the mechanism.
This brings us back to a problem we saw in the Mac world many times already. This time, it’s not evil widgets or fake MP3 files. It’s a shell script extravaganza. Safe files, you said? (Yes, I know, with quotes.)
Personally I feel that in this case, Apple is to blame. Ideally Safari should ship with this option off by default. And more importantly, Safari should never run Shell Scripts. Just check that the download is actually a picture or movie or whatever!
The risk is much greater than Safari, even with "open safe" disabled it is still possible to end up with a file that presents itself as a jpg, (or anything else) that when double clcked will execute as a terminal script.
ick.
Reading the referenced article leads to the conclusion that it would be a good idea if Apple changed terminal so that it requires a "shebang" line at the top of shell scripts. And Safari should check the zip metadata file for suspicious things like assigning terminal to open what are seemingly data files. This would correct the current problem in detecting "safe" files. Of course it is probably still a bad idea to download and open something automatically.
It seems that in Tiger, Apple tried to warn the end user when something that can be launched is downloaded in Safari. Though, I find that the warning appears much too early, so it is often shown even if there is not really anything that could be launched. Showing the dialog too often makes it tempting for the users to just dismiss it, since it laks precision too, and I guess a shell script disguised into a jpeg wouldn't even trigger the dialog.
So the best solution, to me, would be that every time something is launched that was never launched before, then the user should be warned. They already have a system for this, it only needs to be more extensive (warn for shell scripts, AppleScripts, etc. as well), and provide more info : the name of the executable, where it is, who is the author, etc. so that we can make sure we trust the executable.
Or course, shell scripts called from command line by the user in the Terminal shouldn't be subject to that.
Fred
Simply rename the terminal.app to anything else. Or better yet, zip it up and disable it entirely.
Most users don't need access to the terminal and Apple should probably set permissions on the application to require an admin password to even access the application. The mac survived for almost 20 years without a command line. It may be time to go back.
I find it surprising to see everyone jumping on the bandwagon in blaming Safari for this problem.
The problem (as only a few Slashdot posters accurately noted) is in Launch Services.
I think the option to open "safe" files is just fine. The problem is that Safari and Launch Services need to more clearly agree on what "safe" really means.
I don't object to changing the default value of this setting to off, but I don't consider the setting or feature itself to be necessarily bad. What needs to be done is not to give up on the idea but instead to make the definition of "safe" more robust. After all, as I have noted in other forums, who downloads a file who does not have the intention of opening it? Whether it is opened automatically or manually -- open is open is open.
And while we who visit tech forums might pride ourselves on being careful and vigilant and thus prefer our own manual inspections to Safari's assessment, as a matter of [b]policy[/b] for users across the board, if I had to choose between the definition of "safe" of Safari engineers versus that of the aggregate of Mac users, I will take the former over the latter any day -- even allowing it is not perfect.
In other words, we are not considering that many naive or unwary users (or even IT people who are just caught off guard -- and we all have such moments) will manually open files which are harmful when this feature of "Open safe..." might alert us to a possible problem. So the irony is that if it is only well implemented, this feature -- when turned on -- might actually INCREASE security rather than to compromise it.
This vulnerability has been around for quite some time, only nobody thought of trying to exploit it until now. Even so, it doesn't work as Heise and other media outlets are describing it. Contrary to what they stated, there is no metadata file in OS X.
Further, just creating a shell script without a shebang line, giving it a file extension such as .jpg and zipping it up will not make it execute via the Terminal. If any of these so-called "experts" and "journalists" had bothered to try this, they would have discovered that Heise is wrong about the way this vulnerability can be exploited.
Thus, this writer for O'Reilly, like all the others, doesn't have a clue of what they're talking about.
Here's what I can't figure out. Do a get info on any of these "disguised shell scripts" (the jpeg or the movie file examples) and the Finder clearly tells you that they are Terminal Scripts.
Obviously a way exists to determine the true guis of these files without checking for a bam line, why did Apple go to the trouble of checking for the bam line in the first place if this is true?
So have you tried downloading the example file from Heise, Jon?
http://www.heise.de/security/dienste/browsercheck/demos/safari/Heise.jpg.zip
OK, very fine: i disabled the "Open downloaded files" option in Safari, and moved Terminal out of the application folder... so what? If i receive a file i want or need to open, i understand i'll be presented with some dialog window giving me the choice to do so or refuse. Then what? How can i know the file is 'safe' or not? i am not paranoid and really worrying about it, i'd just like to understand the process, it seems to me that the remedies offered don't solve the practical challenge: how to open the file i need AND not get infected. Am i missing something?
Oh and by the way, disable embedded images, javascript, Flash, css and while your at it .html from Safari. These are downloaded and parsed automatically when you visit web pages! You never know, maybe next week someone will discover a way to execute malicious code inside a .JPG file, having these opened automatically inside Safari is asking for trouble!
Seriously I don't find dangerous having Safari automatically open a downloaded .JPG in preview. JPEGs are safe files for all I know. ZIP by themselves are safe, so I don't see a problem of having them automatically decompressed.
So I like this option, and as much as I trust Safari not to erase my home directory via javascript, I trusted the option.
Apple will have to make some serious changes to this function, but if they do the right thing I'll turn the option on again.
The key problem here is that Safari will label the script as a safe file because of the extension, but the launchservices will launch the file as a script. Safari should use the same metadata as launchservices to identify the file. If they can fix that, I'll trust the option again.
And to address the article more directly:
"In fact, it seems every time an application accepts executables from the outside world and processes them automatically, someone has found a way to exploit them, no matter how secured, protected, isolated they are made."
This is a bug, not a feature in Safari, Apple never intended downloaded executables to be executed automatically, unlike Outlook, where it was a feature.
Mike A,
Indeed, better detecting what kind of file is actually downloaded seems key here. It is however, not an easy affair by any means, especially given the current inconsistencies between file extension and resource fork handling within Mac OS X.
FJ
TonyT,
There indeed is a fundamental risk here that should not be overlooked.
FJ
Fred,
You raise an extremely valid point and such a warning dialog would probably be a good solution, even if a very difficult one to implement, both technically and interface-wise. One has to wonder however where to put the limit. Indeed, a malicious program could potentially impersonate user typing and call scripts from a Terminal session so as to bypass the restriction.
I guess the overwhelming number of dialogs the average user would see would such a feature be implemented was key in deciding not to go that way - and it seems this currently holds true for all operating systems.
Jeepish,
You are right indeed and LaunchServices is the fundamental system component that looks like it could use some re-thinking. The reason I was focusing on Safari here is because it is the browser used by most beginners in the Mac world and, at the same time, is the only browser I know that ships with this option enabled by default, as well as presents a confusing interface on the dangers of the feature.
Otherwise, indeed, this problem does not fundamentally lie in Safari.
FJ
Jeff Mincey,
You raise an extremely valid point - and one I attempted to touch upon in my entry as well. Indeed, would this feature be near-perfect, it would increase the security of all downloaded files and of all users by systematically warning users of discrepancies it may find. Should Apple decide to go all the way and implement it, though, I would hope the check subsystem could be made an open component into which all browser developers could tap freely.
FJ
Jon,
You will notice I have started this entry with the word "apparently". My focus here is not on the vulnerability itself (which has been confirmed by many people) but on one particular Safari feature and on whether or not some features should see the light of day. There are excellent security experts on the O'Reilly Network as well as on other sites and I am certainly not attempting to replace them in dissecting this vulnerability.
Also, this entry was written before most US sites published their own articles on the topic, which further explains why it is not of an analytical nature.
FJ
Jean-Paul,
As a general rule, this vulnerability here will allow you to get "infected" (I'm using quotes here as we still lack clear examples) should you accept a specially crafted file containing a disguised shell script. That vulnerability does not make all files you get sent dangerous in any way.
Accepting files from people you know AND ascertaining first they sent it to you on purpose before opening them is the only real way to ensure you will not get infected. Also, once an archived decompressed, before double-clicking on its contents, you may want to use the Finder's Get Info window to double-check its file type and ensure it does not use a custom icon.
FJ
Marco,
JPEG files were actually used as a vector for infection on some platforms a while ago and vulnerabilities are increasingly found in programs that open and display images meaning an image can assist in the execution of arbitrary code.
In that, yes, surfing is a risk and one that we can only do our best to mitigate. The problem here doesn't lie so much in the unzipping of the archive but in the opening of the file within it.
FJ
Marco,
You are entirely right in pointing out I used the word "executable" loosely here. By it, I meant files of a very diverse nature, including those that trigger some action before they can be used (like archives or some QuickTime files that establish network and peripheral connections). Indeed, Safari is not supposed to accept and automatically open executables and the current situation is the result of a bug. My using that word comes however from the fact I believe many rich file formats have now started to migrate files from the realm of data into the realm of actual executables.
FJ
The source of this trouble is the "feature" of the terminal to execute shell scripts by double clicking. A shell script is not a document that one can open safely - its an application, and you should get at least a warning when you try to run unknown shell script, or simply run them only explicitly from the terminal.
Check http://nirs.freeshell.org/safe-terminal/ - an input manager that prevent opening and execution of files in the Terminal.