250180 - Shell: protocol allows access to local files and can lead to a DOS

Status: VERIFIED FIXED

(Core Graveyard :: File Handling, defect)

Description

[Keith McCanless]

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

Comment 1

[timeless]

Attachment: blacklist it

Comment 2

[Mike Shaver (:shaver emeritus)]

Comment on attachment 152534 [details] [diff] [review]
blacklist it

Yes, please. sr=shaver

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 152534 [details] [diff] [review]
blacklist it

thanks

Comment 4

[timeless]

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

Comment 5

[Daniel Veditz [:dveditz]]

Presuming to mark blocking aviary

We really just need to turn off external protocols

Comment 6

[Daniel Veditz [:dveditz]]

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

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Bug 163767 is where we argued for turning external protocols into a whitelist.
Darin argued against it.

Comment 8

[Asa Dotzler [:asa]]

The exploit is public so no reason to keep the bug in the security group. Opening.

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 250379 has been marked as a duplicate of this bug. ***

Comment 10

[Jesse Ruderman]

*** Bug 250356 has been marked as a duplicate of this bug. ***

Comment 11

[Steffen Wilberg]

Aviary checkin was on 2004-07-07 15:07.

Comment 12

[Brant Gurganus]

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.

Comment 13

[Keith McCanless]

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 

Comment 14

[Mike Shaver (:shaver emeritus)]

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!

Comment 15

[David Edwards]

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.

Comment 16

[Daniel Veditz [:dveditz]]

Did you restart after applying the patch?

Comment 17

[drb24]

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.

Comment 18

[David Edwards]

(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.

Comment 19

[Christian Eyrich]

(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).

Comment 20

[Brett Walters]

Will this only patch recent (1.7+) versions of Mozilla, or is will it work for
older ones as well.

Thanks,
Brett Walters

Comment 21

[Daniel Veditz [:dveditz]]

Works on older ones too -- but you should upgrade to get other security and bug
fixes.

Comment 22

[timeless]

[e-mail]: 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 ...

Comment 23

[Marc Bejarano]

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"??

Comment 24

[Billy Newsom]

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.

Comment 25

[Robert Parenton]

[e-mail]:  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.

Comment 26

[Thilo Straub]

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

Comment 27

[Marc Bejarano]

keith: can you update the summary as per comment #23?

Comment 28

[timeless]

[e-mail]: 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.

Comment 29

[Marc Bejarano]

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

Comment 30

[timeless]

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.

Comment 31

[Marc Bejarano]

"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

Comment 32

[Tracy Walker [:tracy]]

verified on 1.7.5 12/15