Wow, that whitepaper (and example) convinced me to install PA. I didn't realize LaunchServices registered URL handlers when you mount a DMG.

It appears using RCDefaultApp to disable the disk: and disks: protocol handlers also closes the hole.

http://www.rubicode.com/Software/RCDefaultApp/

rentzsch, your solution closes the hole if the infection vector uses a disk image. If it uses ftp or afp or smb or ... you've still got problems. There's a working test case that uses ftp to mount the malware app, for example. I think it was on the MacNN thread where we're discussing this stuff.

Jason,

Isn't PA allowing FTP access?

And if so, shouldn't it prevent FTP because FTP is an infection vector?

petey - but PA will block the help:runscript vulnerability (so will the Security Update), as well as blocking malicious registered URL schemes, so while ftp: could still mount the disk it won't be able to actually trigger the app.

kevin,

I could be wrong about this, but...

If a mounted FTP can talk to LaunchServices and reassign (overwrite) an existing URL type handler, then once the FTP point is mounted, PA would be rendered impotent. The malware could reassign a "safe" URL type handler like HTML to itself.

But I don't know if it's true or not that mounted malware can reassign an existing URL type handler. Jason could answer this, perhaps?

correction to immediately above post:

change HTML to http://

Sure, it can register itself as a handler for http, but that doesn't re-set the default handler for that protocol to itself, it just says it *can* handle it. If something else already handles it and is set as the default handler for it (ex. Safari is default for http for me) then the new app can't override that without actually launching and modifying it (and the goal here is to keep it from launching, so it doesn't get a chance to modfiy the default handlers)

I would like to see some method that would allow disk images and perhaps even applications themselves to be digitally signed. Not encrypted, just signed. And then users could decide which signers they want to trust, and only open those images and/or apps. It still wouldn't be perfect, but it would protect users who have common sense, and would provide an "audit trail" in that if any malware was released, it would have to be signed by somebody (or suffer being obviously suspicious) , so it would be traceable.
And let's not have any Windows-style "always trust this signer" BS please. Maybe as a very, very hidden option for advanced users, but nothing that the average user can click on, without knowing what it is.
The administrator of each computer should also have the ability to restrict users to either a. no image mounting b. only signed images can be mounted or c. any image can be mounted, user's choice.

Ideally, I would like to see images/apps signable by any certificate that works to sign email in Mail.app. They could just add signing into Disk Copy.

I also think it would be worthwhile to have functionality similar to PA built into the system, but with the addition of someone else's suggested "don't warn for this protocol in the future" checkbox. Unless there is a much better solution available.

I have a question about which URL schemes PA whitelists. Ideally, it would permit everything within the /Applications hierarchy to employ whatever schemes they want (for example, I believe pop-pop uses a pop-pop:// scheme for its web tracker) while restricting only unisntalled applications from outside (mounted disk images, ftp services, etc.) Is this how it actually functions?

-reg

kevin,

thanks for the clarification. that's good to know. if my scenario had been true, this problem would have been even hairier than it already is.

---

reg,

in the VersionTracker comments for PA, Jason lists the very few URL schemes PA whitelists.

your solution seems to be a decent one, although i'd prefer a more LittleSnitch-like approach.

i'd guess Apple isn't going to fix this soon enough that more work by Jason or Slava wouldn't be warranted.

ultimately, it seems Apple should modify LaunchServices to not register URL schemes that aren't on the boot drive, or some similar criteria.

I saw the link on MacNN about it http://daringfireball.net/2004/05/telnet_protocol
I was about to ask you if PA applys to that too, glad to know it does. Thanks again for PA!

There's an exploitation you missed. If you request a URL with an unknown, unregistered protocol, the system will look in the root level of all mounted volumes for a program with the same name as the protocol. If it finds one, it launches that program.

So it isn't necessary to register a protocol. Just make an application called "foo" and redirect the browser to a foo: URL.