User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 On this specific page, when I load it on my 1.0 version of Firefox, I download a file named ram.jsp - this file is simply a link to a REAL Audio media file. However, the JSP file automatically downloads and my copy of Dreamweaver MX 2004 opens. I tried the page in Safari and the downloaded file appears on the desktop for a brief moment as ram.jsp but then automatically converts to ram.ram and opens Real Audio Player as it should Reproducible: Always Steps to Reproduce: 1. Visit site 2. CLick on one of the movie tiles after the pages has loaded 3. Watch Dreamweaver open Actual Results: The results as mentioned in the description Expected Results: It should not have launched Dreamweaver, first off. It should operate as Safari does and have the file converted to ram.ram
Why is opening Dreamweaver a security hole?
The fact that Dreamweaver opens potentially means a user could download a file which is possibly a mini application and have it run without them knowing about it. For example, if Dreamweaver can open without my permission, why not an AppleScript which has commands to erase the drive of the user using some simple Unix commands. This was an issue with Safari at one point and Apple put a workaround fix in the OS by not letting users run an app for the first time without the user first being alerted by the OS. HTH, Denis
why is this bug confidential?
I only left it as confidential just in case it is a verifable bug and not just a glitch on my system. Why let the world know about any potential holes before being able to fix them?
(In reply to comment #1) > Why is opening Dreamweaver a security hole? Jesse, I gave the example of the possibility of opening other applications on the users system as a potential security hole and to test, I tried Apple's own Applescript site with some example and Firefox acts appropriately and pops up a warning regarding opening an application. If on a Mac, click on the AppleScript icon on http://www.apple.com/applescript/uiscripting/01.html. I can not recall specifying Dreamweaver as an app to handle JSP pages, so I'm still at a loss as to why Dreamweaver fires open when Firefox loads one of the links, whereas Real Player opens up in Safari.
Un-hiding bug to see if we can get some confirmation.
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
I just looked at this in a Camino branch build from this weekend and the latest Fx branch nightly. In Camino, the file (I clicked on the "Harry Potter" item) is downloaded and ends up with a RealPlayer document icon, named ram.jsp, and launches RealPlayer (if I enable the "open downloaded files" pref). It also has valid RealPlayer document type and creator codes In Fx, the file is downloaded and ends up with the document icon for my default HTML editor. It still launches RealPlayer for me, however, rather than my default HTML editor (when I choose the option to "Open with" in the Fx "What should Fx do with this file?" dialogue). However, the file has an "invalid" ("garbage") type and creator code. Looking at the headers with curl, the file(s) are being sent as audio/x-pn-realaudio. I tried several other entries, and all worked the same way, except for one time when clicking on the "Must Have Gadgets" item in Fx. It opened my default editor instead. Clicking on the item again to download a new copy worked like all the rest of the files did in Fx, editor's document icon but opened in RealPlayer. I noticed that each of the ram.jsp files downloaded by Fx had different, random (and sometimes "invalid"/"garbage") types and creator codes. It sounds like Fx is not properly setting type/creator codes to match the MIME types on downloads, and then the OS is choosing an application binding based on the extension (which is the Mac OS X fallback when no other, more authoritative metadata is present or matches). In the reporter's case, Dreamweaver's Info.plist probably declares it as an editor for the .jsp extension (my editor does), so whether the user has chosen Dreamweaver explicitly for a .jsp handler or not, the OS sees it can handle .jsp and uses that binding since the OS can't match the (more authoritative) garbage type or creator to an app. This still doesn't explain why the files sometimes open in RealPlayer even when they have the editor icon and sometimes they open in my editor. Hmm, having written this, I've gone back and tried again and the files are consistently being downloaded by Fx with valid type/creator codes and thus getting the RealPlayer icon, and I've finally gotten Camino to download a couple as editor docs with garbage (and semi garbage, a wrong-but-valid type code) codes. In Camino's case, they always seem to open in the editor when they end up the with the editor document icon. In bug 90918 comment 77 (and in other discussion in bug 154580), Torben notes--if I understand correctly--that sometimes the download code tries to tag the temp file rather than the final file, which may be part of the problem. I know Josh wants to rip out the setting of type/creator codes, but that won't help here (or in other cases where there is dynamically-generated content that doesn't include a separate filename header or a "standard" extension in that filename, which seems to be very common with these sorts of audio/video clip sites); we'd end up opening *all* of these files in the editor app (or whichever app the OS determines should open files with .jsp extensions). Since Safari doesn't set type/creator, it seems to get around this problem by rewriting extensions instead (in order to try to match the MIME type to the app that should handle it), which I don't think is a good idea (we have a couple of Camino bugs filed to root out that behavior).
This bug was reported using Firefox 3.0 or older, which is no longer supported. The bug has also not been changed in over 500 days and is still in UNCO. Reporter, please retest this bug in Firefox 3.6.10 or later using a fresh profile, http://support.mozilla.com/en-US/kb/managing+profiles. If you still see this problem, please update the bug. If you no longer see the bug, please set the resolution to RESOLVED, WORKSFORME. This is a mass search of unconfirmed bugs that have no activity on them, so if you feel a bug was marked in error, just remove the CLOSEME comment in the whiteboard within the next month.
No reply, INCOMPLETE. Please retest with Firefox 3.6.12 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.