Closed Bug 250180 Opened 18 years ago Closed 18 years ago
Shell: protocol allows access to local files and can lead to a DOS
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 This notice covers BOTH a security concern and a DOS. 1)Using the "shell:" prefix in addresses on a windows PC allows access to the local file system. AFAIK all shell shortcuts in IE will also work in mozilla. Addresses such as "shell:cookies" passes the call to explorer and it shows the desired location. Address to individual files or cookies are handled by Mozilla and treated as a "file:" protocol. While I have not looked into the exploitability of this behavior, it would seem to be a security risk as IE has supposedly dropped this functionality in SP1 for IE 6. 2) By making a request for a file that does not exist on the user's system using the "shell:" prefix, Mozilla will continue to open windows until the user's system crashes. So even if 1) is not percieved as a true bug, 2) definately is a bug. Examples of both at http://www.mccanless.us/mozilla/mozilla_bugs.htm Reproducible: Always Steps to Reproduce: 1.See example site 2. 3. Actual Results: various see above and example site Expected Results: denied access to all local files
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: file-handling → timeless
Status: NEW → ASSIGNED
Comment on attachment 152534 [details] [diff] [review] blacklist it Yes, please. sr=shaver
Attachment #152534 - Flags: superreview?(shaver) → superreview+
Comment on attachment 152534 [details] [diff] [review] blacklist it thanks
Attachment #152534 - Flags: review?(cbiesinger) → review+
mozilla/modules/libpref/src/init/all.js 3.515.2.9 mozilla/modules/libpref/src/init/all.js 3.465.2.5 mozilla/modules/libpref/src/init/all.js 3.531
Presuming to mark blocking aviary We really just need to turn off external protocols
From Full-Disclosure: --------------------- This is dangerous. Based on the file extension of the shell protocol different applications may be launched. For example: shell:.its will launch Internet Explorer and shell:.mp3 will launch Winamp. The trick is to find an application that will overflow when given a very long parameter. A quick check showed that a buffer overflow occured within MSProgramGroup (WINDOWS\System32\grpconv.exe) after around 230 bytes with the following URL: shell:[x*221].grp EIP can be controled, but exploitation is a bit tricky since parameter is stored as unicode. Also Winamp contains an BO (no unicode here). Tested environment: Windows XP pro + FireFox 0.9.1 /Andreas Sandblad -------------------------------- You can also do things like shell:windows\UninstallFirefox.exe
Bug 163767 is where we argued for turning external protocols into a whitelist. Darin argued against it.
The exploit is public so no reason to keep the bug in the security group. Opening.
*** Bug 250379 has been marked as a duplicate of this bug. ***
*** Bug 250356 has been marked as a duplicate of this bug. ***
Aviary checkin was on 2004-07-07 15:07.
I am not sure the exact procedure, but in the case where it opened many windows, I was able to use ALT+F4 down to the last window (which had multiple tabs and so it wouldn't close). I then clicked cancel on the dialog and the windows quit opening. That might be investigated and noted as a workaround if you become victim to this issue.
As the one who reported this concern Mozilla, I am discouraged that you credit a post on FD with the find. See http://www.mozilla.org/security/shell.html My report was cleary before that post and the author of that post acknowledges this fact. Does this mean that potential security bugs in Mozilla should be reported to FD first if one wants credit for the find? Looks that way to me. As a security professional who depends on positive publicity, I hope you can recify this situation and reward someone who came to you first. Keith McCanless
Keith, The Mozilla Security Team apologizes for that error; I've corrected it in the web site CVS, and it should appear on the shell.html page within the hour. Thank you again for your prompt report, and help with test cases. Sorry!
I applied the security patch to 1.8 alpha 1. Nothing appears when I do about:config and filter on shell. I can still fire up Windows Explorer with shell:cookies etc. when I go to the McCanless page. The non-existent file problem doesn't crash my browser.
Did you restart after applying the patch?
Whiteboard: RESTART after applying patch!
This "fix" seems to disable Firefox (0.9.1) recognizing shell: as a URI scheme. Rather than the "Expected Results" mentioned in Kevin's original report, the browser resolves the shell hostname and takes me to their site. I am sure the oil company appreciates the extra traffic but believe an error (say "scheme not known" or "unsupported protocol") would have been much more appropriate. Further, most of the links on Kevin's example site are no longer recognized as such even though they are correctly formed from an HTML and URI perspective and should be highlighted (and result in an error when used). As a general practice, it seems incorrect to check URI resolvability while rendering a page. The URIs in question are actually correct though Firefox no longer supports them (thankfully), making this rendering choice doubly questionable. I would suggest reopening this defect for a more complete fix or starting a new bug around the general question of handling unsupported URI schemes.
(In reply to comment #16) > Did you restart after applying the patch? No I did not. The fix works properly now. Apologies if I didn't RTFM.
(In reply to comment #17) > Rather than the "Expected Results" mentioned in Kevin's original report, the > browser resolves the shell hostname and takes me to their site. Well, only if you're using domain guessing. > I am sure the oil company appreciates the extra traffic but believe an error > (say "scheme not known" or "unsupported protocol") would have been much more > appropriate. Yes, I expected mozilla to behave exactly like on Linux where the "shell is not a registered protocol" alert pops up. Apparently disabling a known protocol isn't the same as not knowing the protocol at all. > As a general practice, it seems incorrect to check URI resolvability while > rendering a page. The URIs in question are actually correct though Firefox no > longer supports them (thankfully), making this rendering choice doubly > questionable. On Linux the protocol is and was always unknown. Here the links are displayed as any other link. So that's another difference to a afterwards disabled protocol. BTW, on Linux the rendering of Links as the alert is the same, if I set the pref to true or to false (default).
Will this only patch recent (1.7+) versions of Mozilla, or is will it work for older ones as well. Thanks, Brett Walters
Works on older ones too -- but you should upgrade to get other security and bug fixes.
firstname.lastname@example.org: this isn't a tech support forum (try irc.mozilla.org #mozillazine), but the fix should work for fairly old browsers. my math says it should work back to about 1.2b. Note that you shouldn't be using anything older than 1.4.x, but ...
i opened bug 252469 to track updating the "Known Vulnerabilities in Mozilla" web page at http://www.mozilla.org/projects/security/known-vulnerabilities.html with info on this bug. shouldn't the summary be changed to something like "Shell: protocol allows access to local files and can lead to arbitrary code execution on windows platforms"??
What is the user supposed to do if "access is denied" when trying to apply the patch? When visiting http://www.mozilla.org/start/1.7/ and applying the patch to a computer which I use, the patch will not install even though the preference for Software Installation is on. What else would cause this, and is this obscure enough to need a new bug opened specifically for this issue? If it might be a common problem, could the workaround be posted here or on the Start page of Mozilla 1.7, etc.? Note that the same patch works on other computers I use and on a different account on the same computer.
email@example.com: As stated in comment #22, this isn't the place for this question. However, your problem is that you don't have write permissions to the Mozilla directory.
When visiting the site "http://www.mozilla.org/start/1.7/", the same like I mentioned in the last security problem (concerning update 0.91-Firefox to 0.92) happens: Firefox was identified by the site frontend as "Mozilla 1.7" or so. In a red frame: WARNING! A security issue affects your build. Please install this patch (572 bytes) and restart your browser.See more information on this issue. This message will no longer appear once you have applied the patch. I read the information about that bugfix, and looked for the term "network.protocol-handler.external.shell". Like being told the value was at "false". My browser is: "Firefox 0.9.3 Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.7) Gecko/20040803 Firefox/0.9.3". Seems to be corrected by the webmaster. By the time: Why is that problem always recurring after a new Firefox has been released and the user visits with the mozilla 1.7-start-page!!? Regards, Thilo
keith: can you update the summary as per comment #23?
firstname.lastname@example.org: i own this bug at this point. please explain why this bug's summary should change. it's not like people are going to file new duplicates of this bug today. iirc people filed many copies of this bug without doing searches.
hi, timeless. the reason i think the bug's summary should be updated is that the bug is linked off of http://www.mozilla.org/projects/security/known-vulnerabilities.html somebody clicking through could easily get the impression that this is just a DOS vulnerability whereas it isn't. hth, marc
i disagree. i expect someone following the link to actually read the description which is fairly clear, or even just comment 0 which clearly indicates that this could be a security concern. and lastly, they can and should read the rest of the bug where it's clearly indicated. the summary is just a summary, not a description. changing it at this point is pointless, expect to *break* threading which is a concern for me.
"the summary is just a summary, not a description." umm.. hrm. not sure what definition of "summary" you use, but whatever... correctness for correctness' sake is obviously not an argument i can make to you ;) cheers, marc
verified on 1.7.5 12/15
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.