I love PA, but do you think you could add some kind of options to permanently suppress warnings for specific protocols? For example, the Help Viewer has been patched, so I know that's ok permanently now and I'd like to avoid that verification. Maybe it could be a check box in the dialog?

Thank-you. Nice to know someone's looking out for us. :)

I use Little Snitch to protect my system and when I try the exploit, it detects that the application "diskimages-helper" is trying to contact blahblah on port blah blah, so at least that gives a warning. . . .

I appreciate the new version and your continued development. Now that the protocols deemed "safe" by default are indicated, I understand perfectly well why my iTMS web link didn't set off any warnings from PA.

Might I suggest the addition to the safe list of "mms:" for Windows Media Player? The only known use of it AFAIK is directing WMP to load a stream.

Johnathan,

It was my idea to whitelist the "rtsp" and "pnm" schemes, which are used by RealPlayer.

But I actually think that's an error now, as it would be to whitelist Windows Media Player's "mms".

I believe the correct philosophy should be to only whitelist schemes which are used by applications installed with the base system. So schemes like "addressbook", "ical", and "mailto" would be the only ones whitelisted as safe.

Otherwise, people who have not installed third party applications like RealPlayer and WMP would be vulnerable to having those schemes hijacked.

Yeah, you have a good point. Maybe an interface in the style of the different prefpanes that allow internet helper apps to be changed would be useful here, so that there would be a predefined "safe list" but the user could also allow/disallow helpers of their choosing from being followed/executed without warning.

I still can't get any of the exploits on the whitepaper to work. I'm running 10.2.8.

First, my machine seems reluctant to use the disk protocol to mount disks over the internet. Second, in the ftp exploit, the ftp volume mounts fine, but then nothing runs.

Then perhaps 10.2.8 isn't vulnerable?

Or perhaps we don't need Paranoid Android? Really, as long as disk images arent allowed to remotely mount (which I've always thought was a dangerous idea for these reasons), then how can this exploit work? As pointed out below, you can't launch a program off of an FTP site.

http://daringfireball.net/2004/05/help_viewer_security_update

And furthermore...

http://www.codepoetry.net/archives/2004/05/22/now_were_getting_silly.php

After reading the new Daring Fireball entry, where John Gruber demonstrates that the ftp exploit doesn't work, I tried a couple experiments.

I tried the ftp exploit on the whitepaper again, and as expected, the ftp volume mounted, but nothing happened. I was curious to see what would happen if I actually opened it in Finder however. I opened it and double clicked on 'OSXMalware'; according to John Gruber (at least on Panther) a dialog should ask me if I want to run a program through ftp. In my case it did not, but I'm running Jaguar (10.2.8).

Since I actually clicked on it, I wasn't surprised when it ran. But then I unmounted the ftp volume and tried reloading the exploit page. This time, it all happened as Unsanity said it should: the ftp volume mounted, and the OSXMalware ran! I did not have to open the volume in finder or intercede in any way.

At this point, I'm not sure which of my actions made the exploit work properly: 1) Opening the ftp volume in Finder 2) Running OSXMalware by double-clicking

I guess I'll try resetting everything and trying this again.

To answer some questions before they're asked, yes, I did try the exploit on the updated whitepaper, and yes, my results were as I describe above. The ftp exploit on 10.2.8 does not work as Unsanity describes.

BTW, I've isolated what I did that *does* cause the exploit to work. After I open the ftp volume in Finder and then eject it and try everything over again, the exploit works. My conclusion so far is that just mounting the ftp volume is not enough; you must actually navigate into using Finder, otherwise the custom URL protocol will not be registered.

I believe if others try this (at least on 10.2.8) they'll have the same results.

At this point, it would be nice if someone could verify John Gruber's comments regarding the ftp behavior on Panther, especially in light of the updated whitepaper.

I haven't tried the FTP exploit yet, but it's perfectly reasonable (and I think John Gruber actually said this) that the Finder registers URL handlers once you navigate to the folder containing the app that handles the URL scheme. However, this is easily factored into the exploit - before running the malware: URL, run a file: URL that points to the folder containing the application. The FTP mountpoint is known (assuming the default mountpoint location hasn't been changed, which in 99.99% of the cases it won't be) so it can open the folder which then registers the URL handler, then it can run the URL.

Joshua,

Nothing in the codepoetry post offers a solution for the problem.

The daringfireball post offers an alternative solution that seems like it should work. However it's more work than PA, hasn't been widely tested, and means you'll lose some functionality.

And you're wrong about FTP not being exploitable. Read the daringfireball post more closely.

While this is probably moving farther off topic, here's what I see as the solution (feel free to post problems with it):

1) Remove the "disks" protocol. I am having a very hard time coming up for a good use for it to justify the security risks of mounting a disk into the file system on the fly like that.
2) Don't allow running programs on FTP servers. The program would have to be copied locally anyway (either that or the performance would be terrible - FTP is not designed for random access like that).
3) Don't register protocols for programs on any remote volume - FTP, remote disk image, SMB, NFS, etc.

Joshua,

I believe item 3 alone would solve the issue.

When are you going to release Labels X

I have been waiting for it for 6 months.

Paranoid Android 1.2 is out and, not only with the ability to whitelist schemes, it also tells you what app will open the scheme in question. But there's a bug. I was just told that "ichat:openbuddylist" would be opened in NSCFString. Odd, eh?

I don't know if I can post it here, but I do have a small issue with PA 1.2. I do use iBeez (a PreferencePane) to automatically open specific applications at given times in the morning. This morning, I got an alert for each and every launch event.

Is there a way to include the application in the exclusion list? As the 'culprit' application is nested within the PreferencePane, I can't seem to be able to add it to the exclusion list (no selection possible from the Add dialog nor any drag and drop functionality in the list).

Thanks,

Raf

Ok, I've read the reports of the exploits. Unless I'm mistaken, these exploits use a meta refresh to mount a disk image/ftp server. You could probably do the same with javascript... Perhaps the way it could be fixed is to disallow non http/https URL's to be opened unless the user clicks on something... However, easier said than done.

Also, I was thinking... You could make a 'trojan'/'worm' outta this. Have a disk image online, have a page where it has it:
download the disk image
open the app on the disk image (it has LSUIElement set to 1 so the user can't see it launch)
then it'd send an html formatted message (w/ the exploit) to everyone in your addressbook
then it'd do some crap w/ your home folder
then it'd unmount itself

This is assuming that Mail can use HTML formatted email and if vulnerable to the expliot (which it probably is, due to it being webkit based). Am I way off base here?

Joe

Raf - select the preference pane, right-click, and choose Show Package Contents. You can then navigate to the culprit program there and drag that to the open dialog for the exclusion list.

I'd really like to see a solution that allows URIs to resolve as long as they point to applications that are actually in specified folders like /Applications or /System or /Library. Block it if it's outside those folders. Problem solved, and no prompting or whitelisting required.

To Kevin. It worked. Many thanks.