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."
Went to the proof of concept, followed directions and it did not execute.
I'm running 10.4.5 with Safari 2.0.3. Looks like not everyone is vulnerable.
So the guys in apple who had the __MACOSX part to zip files didn't communicate that to the Safari folks. Communication gaps happen, but this is gross oversight in a company which claims to sell their software for a premium because it is cool (and well-tested UNIX background).
Shell vulnerabilities seem to be the entry point usually, seeing the firefox shell:// that was recently discovered... Integration comes with its own sweet price.
Quidquid latine dictum sit, altum videtur
This is quite a nasty little exploit so I suggest making the change ASAP.
I did this years ago.
Can someone remind me what is the point of a browser allowing "driveby downloads" and automatically launching the content of the download?
Safari has a nice download manager that lists the most recent downloads, and by simply double clicking on the one you trust and want to view is up to you.
This is at least over a 1 year old issue: http://www.net-security.org/vuln.php?id=3461
Is it too much to ask for normal users to double click on a file to launch it? This is what we used to do, and still do with email, ftp, removable media, networked drives, everything. What is the point of a driveby download and launch?
I remember quite distinctly the horror I felt when I first got my mac and discovered that it automatically opened safe files... At least around 10.4.2 or so, this was default behavior. And this option has carried on with me to 10.4.5, but is disabled today.
Why isn't Secunia being flamed here for releasing details of an exploit before Apple has had a chance to patch it? Are there not enough details for someone to create their own version? I may be wrong, but I did not notice one mention of any fact that indicates that Apple was notified of the problem and/or given an opportunity to fix the problem. I am used to seeing such information releases eing labeled as "irresponsible" but I have not seen any discussion of this aspect of the story yet.
Laws affecting technology will always be bad until enough techies become lawyers.
None of the steps involved in causing this attack to happen should have been implemented in the first place. They're all well-known to be risky, and have all been used in exploits in the past.
"Open Safe Files After Downloading" is inherently risky. No files should be considered safe. The user should always make an explicit request to open any file not handled by the browser itself. Approving an action requested by a potential attacker is not making an explicit request: even if Safari detected the executable and popped up a dialog it would still not be good enough to prevent many people from reflexively approving it.
In addition, automatic execution or interpretation by a general purpose scripting language of any files in an archive, removable media, disk image, or any other potentially untrusted container is inherently risky. Executing code, using applications found in the volume as handlers, or otherwise using them, should be deferred until the user has explicitly requested the code be run, installed, or used.
This should be such a fundamental principle of secure software design that it shouldn't have even occurred to Apple not to follow it.
Just being less insecure than Microsoft is not enough. One might as well laud smallpox as being less deadly than Ebola.
(and... I told you so)
So where are all the 10 year old nephews who can go under the hood, break things, but do it in such a way that the car can still drive around and duplicate the problem in every car it passes? Now THAT would have me impressed.
I love my sig.
How about another analogy: locksmith vs lockpick. I was taught how to pick cylinder style padlocks by a kid two years younger than me while I was in high school. It was a simple matter of the right tools, a little dexterity and practise. I knew another kid who learnt how to crack the dial-combination style padlocks. All that required some luck, lots of patience and sensitive fingers. In both cases the lockpicker was completely ignorant of the internal design of the lock concerned, and didn't care either.
When I was a bit older I learnt how to crack DOS games with a hex editor. Yet I could barely code "Hello World" at the time.
There are some skilled and knowledgeable hackers out there (fewer than you think), but skills and knowledge are not a prerequisite for hacking into a system.
...but it could well be related to the transition, or more precisely, the fact that a haxx0r can now install OSX on a space partition on a PC and start coding with it rather than having to buy a Mac just for the privilege. In fact I'd put money on this is exactly why we are suddenly seeing a lot of attention with OSX security as OSX now has a completely new audience that can obtain the OS and start coding with it for free.
The problem is dug very deep in Mac OS X: One does not know if one can trust a certain file or not. A patch for the current security hole is easy, but won't solve the real problem.
On Mac OS (9 and X) a file can have an arbitrary icon and type, independent from its name. Some systems use the filename to guess type and icon. On Mac OS this information is stored as separate data, in a so called ressource fork. So one could create a file "some_file.xls" that is a text-file and has the icon of photoshop. Or one could create a file "celebrity_naked.jpg" that is indeed a program and has the icon of the preview application --- or worse whose icon shows a naked person. Even when there is no security hole, the user might eventually try to open this file. With the current security hole this step can be skipped --- the browser will open it automatically.
Mac OS X needs a way to mark a file as trustworthy. When a file is not marked this way, several dangerous operation will be disabled and the file must be marked in a certain way in the file browser (Finder, open dialogue, etc.). I think the Finder should have an extra check box in the file info dialogue: "This file is trustworthy". Terminal, Help Viewer and other easily exploitable application should refuse to open a non-trustworthy file. And this files should be viewed with a big red explanation mark on their icon --- at least when they can be opened with a dangerous application. So the user can easily see, that these files are a potential threat. Of course, per default only the system files are marked trustworthy.
An easy way to implement such a "trustworthy" flag would be extended POSIX attributes. On Mac OS X 10.4 every file can have an arbitrary number of these attributes. I suggest the following scheme: A file is only trustworthy, when it has a certain attribute. The name of the attribute depends on the user, its value is a digital signature of the file; e.g. name="trustworthy:34833066-DC6A-459F-8462-7100E84A D100" value="Here comes the signature...". Additionally there are some virtual accounts for the machine and the administrator. When they trust the file, every user on the machine or the domain implicitly trust the file too. This scheme has several advantages: