Slashdot Mirror
Mac OS X Struck By Severe Security Hole
An anonymous reader writes "Macworld is reporting about a new security hole in Mac OS X that can be exploited to compromise a system if the user simply visits a web site with Safari. Currently, no vendor patch is available. Secunia has a demonstration of the vulnerability and suggestions for temporary workarounds."
You can test this by downloading this harmless exmaple:
http://www.heise.de/security/dienste/browsercheck
...and sending the resulting JPG to yourself in Mail.app.
This is rooted in something that has been true about Mac OS in general for over 22 years, which is that any file or document - including executables - can have any icon. Other elements of the OS (such as the Get Info window) properly identify it as a Terminal document (shell script), and show that it is opened with Terminal, but most users won't see or understand this.
I'd expect a security update that addresses this *very* soon. This is a bad one.
I don't use Safari because it doesn't render pages as well as a mozilla based browser, and now I have a reason to gloat :)
Get Camino here. Camino is an OS X native browser using the gecko rendering engine. Looks better than Safari, is faster than Safari, and apparently is more secure than Safari. Plus the security is more easily tunable.
Most Mac users have heard of it by now, but I'm just giving them another plug because it kicks ass.
The 'workaround' is to just disable auto-opening 'safe' files. I've done this on every Mac I've used, since I started using them, as I always saw it as a potential security risk (and a potential annoyance - I don't want my files opened immediatly sometimes). In my mind, automatically doing almost anything like opening downloaded files without asking is bad.
So just live without automatic file opening for the time being, and you're safe.
"Your effort to remain what you are is what limits you."
Mac OS X users can protect themselves simply by removing the check mark from the "Open safe files after downloading" option in Safari's preferences under the General tab. I have tested this and it works. This is quite a nasty little exploit so I suggest making the change ASAP.
Strange women lying in ponds distributing swords is no basis for a system of government.
The only difference is that the default behavior in Safari is to automatically open downloaded files of certain trusted types.
Who wouldn't try clicking on a movie icon? I would think that most people would.
Putting moderation advice in your
Better integration with the keychain and mail, as well as a native appearance. Me, I use Firefox.
There's also Camino if you want something that looks native. It's gecko based, but doesn't have the extendibility.
Someone correct me if I'm wrong, but this exploit can only affect items that the user has rights to. If a script were written to make changes to the system, OSX should prompt you for your password, right?
Kiteboarding Gear Mention slashdot and get 10% off!
Quick point of order: the bug doesn't execute automatically if you turned off the "Open Safe Downloads" preference. However, it's still really Really REALLY bad.
Explanation: Apple recognizes a particular folder within a zip archive as resource forks. This way you can correctly upload/download old-style apps and/or OSX metadata. The latter feature is where the problem occurs.
If you take a shell script, rename it to a "safe" file extension (such as mov, jpg, etc), then change its metadata (aka the "Open With..." setting) to Terminal.app instead of the expected default application, you now have a shell script that looks like an ordinary media file.
If you then use OSX built-in BOMarchive command, you have a zipped shell script that looks like a "safe" download.
End result: arbitrary shell script execution (under OSX default settings) upon visiting a malicious URL.
Conclusion: remote metadata should not be trusted. This bug would not occur if downloaded files could only belong to their default app.
It's just another choice you're free to make. I like Safari a lot more than Firefox, because it works the way you would expect a Mac app to work. I haven't tried Camino yet, though.
No, it does NOT ask for an admin password, however you need to be logged in as a privledged user (administrator) for it to work. A standard user clicking the test link does not execute calculator, an admin user does. All the more reason to not do your everyday work in an administrative account. My test was Safari 2.0.3/OSX 10.4.5. Now if the code tried to do something more system wide through the terminal window it opened, it would probably require a su or sudo authentication. Opening a program or executing some simple code is enough to cause some problems though.
The Opensource virus scanner ClamXav (based on ClamAV) already scans for this. I simply set it to watch my desktop and mail downloads folders. I even tested it by downloading the sample file and sure enough, it warns me both in Safari and in Mail.app
It takes more than just visiting the site to be compromised. You have to download a zip file.
Because this was reported by Heise via Michael Lehm via mac-tv.
I actually played around a little bit this morning trying to make my own 'evil zip file' It's not trivial, but it's something that someone with 1/2 a clue could whip up in an hour or so, or make a shell script that Kiddies could use to automate the creating of evil things.
The parent here is spot on. This isn't a Safari or Mail problem. This is a problem in how the zip launcher handles embedded meta-data. It's ripe for 'Kornikovina.jpg' type exploitation.
What if it is just turtles all the way down?
FWIK, the JPG extension wasn't really necessary. I think that if you had a properly-formatted shell script, that starts with a shebang line, even if you give it a bad filename extension, Safari will still recognize it as "unsafe" and won't execute it.
The problem occurs when you have a shell script without the shebang line, and it's given Type/Creator codes so that it will open in Terminal.app (which will happily execute shell script without a shebang line, in the user's default shell). The name is unimportant; the only purpose it would serve is to make the user more likely to click on it on the web page. Which, as other people have pointed out, isn't really necessary since the file could be set to download automatically by the page. Clicking a link ON the page isn't necessarily required.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
Um, not you're not - or you wouldn't have written in your original post:This vulnerability has nothing to do with icons.
OK - I guess its true that you're aware now you've read other posters detailing how this works.
Also, in case you hadn't noticed, getting a user to visit a web site is still a social engineering principle.
Not if the website's been hacked.
Once fixed (or, in the interim, a single box unchecked) every other aspect of this just becomes tricking the user to click something.
The fix should have been to disable the "Open safe files after downloading" option by default a year ago - Apple's failure to do this is fairly typical of a large software company trying to balance security & ease of use.
And as we all know, that can happen on any platform.
I am not aware of any way you can execute something under Ubuntu without explicitly setting the execute bit.
Please link to examples.
My pics.
The lesson to be learned is that Apple needs to be hit with a clue bat. Their system is not as inherently unsafe as Microsoft's (the problem is in the safari shell application, not the Webkit itself), but they're not continuing to apply the same good security practices that the operating system they inherited had been using.
The solution, I suspect, is to simply not auto-open *anything* that isn't handled by the downloading app itself.
Or by a plugin designed to work with the downloading app, that is intended to implement the same security guarantees.
It would actually be reasonable to call external applications for *some* files, but only if they were able to register as applications that are intended to handle untrusted content.
Unfortunately, Apple's LaunchServices doesn't qualify as such a registry.
(not to mention that having ZIP files automatically unpacked is something I personally find EXTREMELY inconvenient and unpleasant, and if they implemented such a registry and if the unzipper WAS 100% secure I would still want to be able to remove it from the list of "safe" applications)
'' Goodness me, I'll admit I don't know that much about the workings of OS X but I'm shocked to hear that meta data stored in a file is trusted in this fashion. ''
No, that is no problem at all. The problem is that two applications (Safari and Finder) used different code to decide whether this is a script or not. Safari thought it was a JPEG file. That would have been no problem at all if the Finder had agreed and had asked Photoshop to open that JPEG file. The problem was that the Finder looked at the same file with the same metadata and came to a different conclusion, believing that the same file was a shell script.
I then created a brand new test account with no admin priv's and tried it and it worked there also.
This is on a fully patched OS X 10.4.5 system.
Just FYI.
"terrorism" and "pedophilia" are the root passwords to the Constitution
Yes, its really a bug in LaunchServices
& q=windows+autorun+vulnerability&ie=UTF-8&oe=UTF-8
& q=windows+vbscript+vulnerability&ie=UTF-8&oe=UTF-8
& q=windows+jscript+vulnerability&ie=UTF-8&oe=UTF-8
& q=driveby+downloads&ie=UTF-8&oe=UTF-8
No it is not a bug, its an implementation error.
No application on a computer should run downloaded code without human intervention.
Javascript is fairly benign. HTML is fairly benign.
"Autorun" in any variety is going to hurt people, See: http://www.google.com/search?client=safari&rls=en
What about vbscripting? See: http://www.google.com/search?client=safari&rls=en
What about jscript? See: http://www.google.com/search?client=safari&rls=en
What about driveby downloads? A new term coined to exactly describe this problem. See: http://www.google.com/search?client=safari&rls=en
A wise man once said, "A smart man learns from his mistakes, a Wise man learns from other people's mistakes."
There is no try. Do or do not. Do not like Microsoft does.
I've updated Paranoid Android to be aware of this class of exploit. You can download it here or grab the source code and compile it yourself.
Note that Paranoid Android is an APE module. I like 'em, but it's something to be aware of.
Basic directions: Run the installer, log out, log back in, launch System Preferences and choose the Application Enhancer prefpane. Choose Paranoid Android. Turn on "Watch non-default application launches". Unless you're really paranoid, turn off "Watch URI schemes", since that class of exploit was fixed awhile ago.
Once you've done this, both the Safari exploit and the Mail.app exploit will trigger a dialog window telling you what's going on and giving you a chance to use the default application (Quicktime Player) instead of the custom one (Terminal).
Once Apple puts out a fix for this, I recommend ditching Paranoid Android - it's a pretty heavy solution.
More info on PA can be found here.
The real bug is in Terminal.app - it runs scripts even if they don't start with the shebang
/bin/sh, which it's supposed to do.
/bin/sh either. The POSIX standard specifies that if the shell fails to execute the script using exec(), if the execute bit is set it should run it itself.
Terminal.app does no such thing. It simply passes on whatever you give it to
It's not a bug in
The "bug" is a pair of known design flaws in Safari that Apple should have fixed two years ago, along with a change in the unzipper that changed the behaviour Safari was mistakenly depending on.