Closed Bug 163648 Opened 22 years ago Closed 22 years ago

URL with "vbscript:" protocol launches MS Internet Explorer

Categories

(Core :: Security, defect, P1)

Product:
Core
Component:
Security
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: sinchi, Assigned: security-bugs)

References

Details

Attachments

(4 files)

Demonstration
288 bytes, text/html
Details
Another demonsrtation - when you click this link, 64 MSIE windows will pop up. Be carefully!
7.69 KB, text/html
Details
Exploit - opening IE with redirection to any URL.
345 bytes, text/html
Details
Patch - blacklist known dangerous protocols
2.88 KB, patch
dveditz
: review+
darin.moz
: superreview+
jesup
: approval+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815

Mozilla 1.0.1rc1 (Build ID #20020815),
Windows 2000 Server SP3
MSIE 5.01 SP2;Q321232

If I click on link with HREF beginning with "vbscript:", MSIE opens with
VBscript operators in location bar. In my case, MSIE is reporting about errors,
but, maybe, another MSIE or Windows versions will execute VB code.

When I click to Reload button in MSIE, VB code runs.

I think, this is critical security problem.

See attachment as demo.

Reproducible: Always

Steps to Reproduce:
Attached file Demonstration — 
Demonstration of exploit
This is IMHO invalid.
vbscript: is a registered Windows-Protocol (like hcp: with WinXP ;)
and Mozilla is doing "the right thing" (TM). If you dont want this, alter you
registry.

BTW: Why should starting/running IE considered an exploid? Millions of lemmings
are doing this every day...
If we'll going to support all protocols which Mozilla doesn't understand as
"native" Windows protocols throw registry, we lose the main advantage of Mozilla
- security.

>Why should starting/running IE considered an exploid?
>Millions of lemmings are doing this every day...
Well-known fact is that MSIE is highly unsecure browser, see
http://www.pivx.com/larholm/unpatched/

If anyone will can launch MSIE on my computer when I see pages with Mozilla (or,
more, if anyone will can place <iframe src="vbscript:..."> in HTML e-mail
message), I willn't see any reasons to use Mozilla as reliable and secure browser.

I was extremely struck when I clicked a link on Web page and MSIE pops up.
Previous versions (0.9.x, 1.0, 1.1b) didn't have this bug, and I categorically
don't want see this in future versions.
if this is a "new" behavior you might be right..
bug 163308 is about something similar.

Because of this, Mozilla will most likely suffer from this
http://online.securityfocus.com/archive/1/287482/2002-08-10/2002-08-16/0
WindowsXP bug.
I don't know if this is designed behaviour or not, but just like we won't launch
an .exe file outright, I think we shouldn't let this happen either. I for one
definitely do not ever want IE to be launched on my computer.
I don't see this behaviour with Build 2002081204 on Windows NT.
I have IE6 installed, but it is not invoked.
Exploit. Javascript can be turned off, this has no effect. You can get this
code even by e-mail.
Build 2002081204, probably, has no problem.

But I see this bug in build 2002081506, downladed from
ftp://ftp.mozilla.org/pub/mozilla/releases/mozilla1.0.1rc1/
mozilla-win32-1.0.1rc1-installer-sea.exe

*** This bug has been marked as a duplicate of 163767 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
This bug shouldn't be duped against a request for a pref.  I think a blacklist, 
like the one we use for known dangerous file types, would be appropriate here 
if we can't get a "this protocol is dangerous" bit from the operating system.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Depends on: noexternalprotocol
Here's a quick & dirty attempt at using this feature to have Mozilla open IE and
direct IE to open a particular URL. If this can be done, then many of the
available IE exploits can also target some Mozilla users.

<img src="vbscript:</script><body onload=document.location='http://mozilla.org'>">

However, unless I disable script debugging in IE, I have to dismiss a script
error dialog box before IE opens the target URL. (And I realize that this won't
work the same on all computers in all configurations. YMMV.)

By the way, the "cdo:" and "vnd.ms.radio:" protocols also open IE (on my pc).

Jason, I confirm, this exploit runs on my system too.
Changing severity to "blocker" because this is really big hole.
See my comments:
http://bugzilla.mozilla.org/show_bug.cgi?id=163767#c25
Severity: critical → blocker
All exploits run also in 1.0.1rc2 (build ID: 2002082306)
Changing priority and target milestone - this bug must be resolved before 1.0.1
release.
Priority: -- → P1
Target Milestone: --- → mozilla1.0.1
manko, don't do that.
see http://bugzilla.mozilla.org/queryhelp.cgi#severity

is this a networking or security bug?
Severity: blocker → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: mozilla1.0.1 → ---
This is an extremely dangerous security bug. Roots of this bug are growing,
certainly, from networking (see bug 163767), but this bug is critical for any
stable release, because it can bring to mass and easy exploiting and cracking of
numerous Moz+Win systems not only during Web-sufring, but even by sending e-mail.

This bug is more danger that notorious bug 141061. Please, change severity to
blocker or critical.
Idea by Jason Summers.
This bug persists also in 1.1 release. Changing severity (oh, excuse me,
Daniel!). Adding an exploit - you can get this code by e-mail and your system
will be cracked.
Severity: major → critical
Adding mscott since he added this feature -- any objection to ripping it out? We
can add a whitelist pref so sites using these features could add some back if
they want to take their chances. End-users would generally make the wrong
choices so shouldn't need UI for this.
Group: security?
I consider this bug critical from security point of view.
Suggest mozilla does *NOT* open external applications in any way without asking
the user.
On windoze some applications register their protocol handlers (like mirc IIRC)
and this type of exploits should not be exploitable from mozilla - the users may
perceive it is mozilla's fault because they got exploited from mozilla.
Does latest Netscape 7 have this bug? If yes, it's very sadly...
Yeah, we should pop up a confirmation dialog for external protocol handlers just
like we do with external helper applications.
@ manko@zhurnal.ru:
I let a friend of me test exploit 1 and 3 on his Windows 98 machine using NS7
(I don't have any Windows-machine here), he said they are working!
Not a good start fow a new Netscape release... :(
I greatly hope, this bug will be fixed soon, and patch for Mozilla 1.1 and
Netscape 7 (or versions 1.1.1 and 7.0.1) will be released in in a few days.

In Russian, "the awl cannot be hidden in a sack", in english, "murder will out".
Time presses... :(

For the moment, I higly recommend return to Mozilla 1.1b as the most safe and
stable.
Adding Ben to demonstrate him dangerous effect of external protocols without
opening a new bug.
Depends on: 167475
Also persists in Mozilla 1.0.1
Blocks: 1.2b
Most security dialogs annoy users more than they improve security.  I don't
think a warning dialog would be appropriate here.  Either there's a huge hole in
some external program that isn't a plug-in and having a warning dialog doesn't
help, or there isn't a huge hole and the dialog is simply annoying.  I would
prefer to blacklist vbscript: but allow magnet:, irc:, aim:, etc. to continue
working with one click.
Why don't we treat external protocol handlers exactly the same as external
helper apps, which pop up a dialog by default?
Blacklist of danger protocols in not a bad idea, but we also must disable using
external protocols in cases other that <a href> (see bug 163767), otherwise
exploit #2 will work anyway with "trusted" external protocols.

I think the best choice might be complete removing external protocols from
Networking core and moving its support in <a href>/<area href> tags binding.
Commenting comments 27 and 29:
Black list is a bad idea, though better than nothing.
I suggest white list, empty by default.
There are huge holes in mirc and IE and probably application foo.
By opening the above automatically, the overall securty of mozilla is equal to
the most insecure application which has protocol handler.
And I strongly doubt the average Joe uses strange protocols.
The user should be aware what mozilla starts - the same way with plugins and
helper applications.
And all external applications should be documented, so I can disable them :)



Georgy, do you agree to me about issue of bug 167475 (enabling external
protocols only in links)? It's a main idea of comment #29, I consider that is
even more important that black/white lists.
I think the important issue is not to start external applications which the user
has not approved. Clicking on a link is considered a safe operation, so I don't
think limiting to <a> is a solution at all.
I agree, but enabling (even with confirmation, even with maximal restrictions)
external protocols in cases other that links is, imho, ideological mistake.

That's my summary from 167475:
Exploits for this bug are dangerous mainly if external protocol
handler is being requested automatically from HTML code via <IMG
SRC="externalprotocol:URL">, <IFRAME SRC="externalprotocol:URL"> and other
similar cases.

With relation to common sense, invoking an external protocol is nonsense in
this case, because <ANYTAG SRC="..."> is request to return some data in browser,
not for launch external application.

Assuming that user has enabled some protocol, for example, irc: to start IRC
chat by pressing a link. He has opened web page with HTML code:
<iframe|img src="irc:some.url.there">

And he has seen IRC window to appear on screen suddenly (without his deliberate
request) and empty iframe (or broken image icon in case <IMG SRC=>) in page.

Absurd, isn't it?
I agree with George. A blacklist is too fragile. Better would be a whitelist
which the user can configure like they do with helper apps, and which Mozilla
distributors can add to --- although Mozilla.org should ship an empty whitelist.
Guninski, comment 30:
> By opening the above automatically, the overall securty of mozilla is equal to
> the most insecure application which has protocol handler.

And you would rather have Mozilla be as secure as the most insecure application
which has a protocol handler plug one warning dialog?  That's a valid position
to take, but I don't think the dialog would gain us enough security for it to be
worth the annoyance.

Guninski, comment 30:
> The user should be aware what mozilla starts - the same way with plugins and
> helper applications.

I'm not notified the first time Mozilla uses the flash plugin.

When a program registers a URL scheme, it's essentially registering itself as a
plugin for all browsers installed.  It doesn't make sense to require a plugin or
plugin mimetype to be whitelisted, so I don't see how it makes sense to require
a url scheme or url-scheme-handling program to be whitelisted.

By the way, mIRC and Shareaza pop up dialogs when you follow irc:// and
magnet:// links, respectively.  These dialogs explain exactly what will happen
when you click ok to the dialog.  This makes the proposed Mozilla dialog
redundant, and makes the application's dialog (which is more important) less
likely to be read.

If Mozilla has a whitelist, applications will find a way to add themselves to
Mozilla's whitelist when they are installed, and having a whitelist won't
accomplish anything.
For comment 35:
>And you would rather have Mozilla be as secure as the most insecure application
>which has a protocol handler plug one warning dialog?  That's a valid position
>to take, but I don't think the dialog would gain us enough security for it to be
>worth the annoyance.

This is much better than blindly executing the external application. An option
"silently ditch everything external" is also an option. 

> I'm not notified the first time Mozilla uses the flash plugin.

On my computer the flash plugin does not start because of it security history -
I have rm'ed it . It is in known location and mozilla advertise it as plugin.
This does not apply for the vbscript: protocol.

>By the way, mIRC and Shareaza pop up dialogs when you follow irc:// and
>magnet:// links, respectively.  These dialogs explain exactly what will happen
>when you click ok to the dialog.  This makes the proposed Mozilla dialog
>redundant, and makes the application's dialog (which is more important) less
>likely to be read.

But the vbscript: protocol does not ask you anything, right?

I vote for an empty whitelist.
The fact that this bug is open shows that there is a bug with vbscript and mozilla.

If the next IE install a protocol msbar: , should mozilla release a new version
to blacklist it?

If a worm takes an advantage of IE's bugs and owns mozilla users, what shall
mozilla.org tell - "it is not our fault, just our blacklist is a bit incomplete" ?




I'm not so much worried about external 3rd party apps that the user may download
and which may, at some point in the future, add themselves to the Mozilla
whitelist. First of all, the user has to install those themselves. Secondly,
they are not likely to accidentally launch Internet Explorer or some other piece
of Microsoft "middleware" with a large number of potential holes.

I'm more worried about the pile of URL schemes that Microsoft ships by default
in Windows that are likely to launch a very large amount of code that we don't
trust and that the user did not specifically ask for. If Microsoft starts adding
those schemes to Mozilla's whitelist, well, we'll fight that battle when we come
to it. But I will bet you one dollar they will not do that.
Win WinXP with SP1, you can delete entire directories by getting the user to
click on a link.

See http://24.78.2.184/helpcenter.htm for discussion and an example (which will
delete a test directory!).

It involves invoking an hcp: url, ironically part of the Help Center code in sp1.

From the page: 

 To try it out, do the following, but, BE WARNED, it will delete ANYTHING you 
 put in the "test" directory. (I should point out, sub-directories aren't 
 deleted, and user permissions may have an effect)

 Create a folder called "test" at the root directory of your hard drive. (i.e: 
 c:\test\) Put some files in it (junk, files you don't care about losing - 
 create some new text documents or something).

 Then, copy and paste the "link" below into your address bar and hit enter.

 Wait a few seconds, the "Help Center" should pop up.. then, once you've closed 
 the help center, check that directory again. You should notice the files in 
 the directory you created are gone..

 This should be frightening to any Windows XP user, because anyone could link 
 it on any webpage.. definatly a terrible flaw in the Windows Help Center 
 included in XP.

 copy and paste this link into your address bar and hit enter..

 hcp://system/DFS/uplddrvinfo.htm?file://c:\test\* - or click here.


Oh yeah, one more comment from there:

 Easy Fix(es)
 ...
 3. <del>Use a browser other than IE</del>
   (doesn't work - mozilla did the same thing as ie)

adt wants this, but we need to see a branch patch to approve.
Guninski, comment 36:
> On my computer the flash plugin does not start because of it security history -
> I have rm'ed it . It is in known location and mozilla advertise it as plugin.
> This does not apply for the vbscript: protocol.

Ignoring the Windows operating system settings for protocol handlers would be an
odd thing to do, considering that one common complaint about Mozilla is that it
does not honor operating system settings.

rm'ing Flash is a pretty geeky thing to do.  Possible geeky prefs:
- A button to open the Windows prefs for URL schemes and file types.
- An add-on that creates a UI for HKEY...\PROTOCOLS\Handler\ within Mozilla's prefs.
- "Alert me the first time I use each installed plug-in".

But since most users don't look through prefs this obscure, we should
concentrate on debating the defaults.


Guninski, comment 36:
> This is much better than blindly executing the external application. An option
> "silently ditch everything external" is also an option. 

You have yet to convince me that putting up a dialog is better than "blindly
executing" the OS's default app for a protocol and using a blacklist for
protocols known to open Internet Explorer.  In my previous comment, I mentioned
two ways it's worse: users are less likely to read mIRC's or Shareaza's more
informative dialogs after seeing our dialog, and our dialog would only protect
some users while annoying most.


Me, comment 35:
>> By the way, mIRC and Shareaza pop up dialogs when you follow irc:// and
>> magnet:// links, respectively.
Guninski, comment 36:
> But the vbscript: protocol does not ask you anything, right?

Correct.


roc+moz, comment 37:
> I'm more worried about the pile of URL schemes that Microsoft ships by default
> in Windows that are likely to launch a very large amount of code that we don't
> trust and that the user did not specifically ask for.

So you're letting Microsoft dictate to us that we cannot make Mozilla as
compatible with plug-in-like programs as Internet Explorer is?
For Comment #42:
Jesse Ruderman, are you aware of the amount of web/email malware for IE?
Do you realize that a very small modification of most of this malware will make
Mozilla on windows vulnerable (via IE) - it will work from both web and HTML email?
Once again blacklist is not a solution.
> > I'm more worried about the pile of URL schemes that Microsoft ships by
> > default Windows that are likely to launch a very large amount of code that
> > we don't trust and that the user did not specifically ask for.
>
> So you're letting Microsoft dictate to us that we cannot make Mozilla as
> compatible with plug-in-like programs as Internet Explorer is?

I'm not letting Microsoft dictate anything. I'm looking at these
Microsoft-specific URL schemes and concluding that on the balance, the security
risks outweigh their usefulness in Mozilla. (Note that most Microsoft-specific
URLs probably won't even work in Mozilla without ActiveX and IE-specific
HTML/CSS/DOM support.)

Note that Microsoft is in the habit of forcing "upgrades" down users' throats so
the list of schemes we want to ignore is quite likely to grow faster than the
user upgrades Mozilla. Hence a whitelist is required.

If we do a careful analysis of a particular URL scheme that seems particularly
useful in Mozilla and particularly risk-free, then we can add that scheme to the
whitelist. Your mIRC and Shareaza protocols might be candidates.

BTW one of my fundamental ideas is that Mozilla.org code should prefer security
over convenience to a greater degree than other distributors of Mozilla.org code
might. This is because it's much easier to detect inconvenience and reconfigure
or patch Mozilla to fix it, than it is to detect insecurity and fix that. Also,
users of Mozilla.org code are on average geekier than most users. So while I
would recommend a whitelist for all Mozilla distributors, if Netscape (say)
decided to change that, or add a number of protocols to their whitelist, I'd
understand.
I think, redundant confirmation for IRC clients (for example) is not a problem -
according bug 167473 user may remember one's decision and afterward see only IRC
client dialogs.

I vote for empty whitelist just now and for whitelist containing well-known
usable protocols (irc://, magnet://, realaudio:// etc.) with confirmation dialog
for each one when bug 167473 will be implemented.

Further, if software developers will want to introduce their own additional
protocols, they may register it in Mozilla whitelist. But remembered user
decisions for confirmation dialogs must be saved in user profile in order to
prevent developers from launching their applications without user confirmation.
Echoing dveditz, adt wants this, but we need to see a patch.
Blocks: blackbird
Keywords: adt1.0.2 → adt1.0.2+
Also see bug 172498..
Comment #8 shows approximately when the bug get introduced.
What about removing the checkin that introduced the bug?
Bug 172498 demonstrates that genie breaks away from a bottle...

I have a suggestion about new algorithm for protocol handlers,
see bug 167475 comment #9

But now we can use this regfile to avoid exploiting:

----- begin of EXTERNAL.REG -----
REGEDIT4

[-HKEY_CLASSES_ROOT\PROTOCOLS\Handler\hcp]
[-HKEY_CLASSES_ROOT\PROTOCOLS\Handler\vbscript]
[-HKEY_CLASSES_ROOT\PROTOCOLS\Handler\vnd.ms.radio]
----- end of file -----

I use this and for the time being don't see something unwanted.
Depends on: 173010
I have entered bug 173010 for discussions about whitelist.
CCing myself & Evelyn Prime MacAdam.
As a short-term solution, we have tentatively decided on a blacklist. Later on,
we could create a yes/no/ask scheme similar to helper apps.

This blacklist includes vbscript, hcp, ms-help, vnd.ms.radio, and javascript
(just in case). Any more we should add?

Reviews needed.
Comment on attachment 102263 [details] [diff] [review]
Patch - blacklist known dangerous protocols

r/sr=darin for the code changes (modulo any changes to the list of explicitly
blocked external protocol handlers).
Attachment #102263 - Flags: superreview+
Comment on attachment 102263 [details] [diff] [review]
Patch - blacklist known dangerous protocols

sr=dveditz
Attachment #102263 - Flags: review+
Mitchell, it's great!

I can suggest this (taken from Windows 2000 & XP system registry):
cdl:
ipp:
its:
local:
mhtml:
mk:
ms-its:
msdaipp:
res:
sysimage:

But, according Georgi Guninski's comment #36, whitelist with mailto:, irc:,
magnet:, realaudio: and, probably, another established and usable protocols
could be a better solution.

I hope, "reverting" logic of patch isn't so difficult.

Comment on attachment 102263 [details] [diff] [review]
Patch - blacklist known dangerous protocols

a=rjesup@wgate.com for 1.0 branch.  CHange mozilla1.0.2+ to fixed1.0.2 when
checked in.

I still do worry about not having a whitelist, but this is a step forward.
When this is checked in to the trunk let's mark this one "fixed" and use one of
the other bugs for the more general/flexible solution since that work doesn't
need to be confidential.
*** Bug 172498 has been marked as a duplicate of this bug. ***
Fix checked in on trunk and 1.0 branch, adding fixed1.0.2.
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Keywords: fixed1.0.2
Resolution: --- → FIXED
Verified on 2002-10-11-branch build on Win 2000

Clicked on the Demonstration and nothing happened. This is the expected result.

Added keyword verified1.0.2. Will change status to Verified Fixed after
verifying the bug on latest trunk.
Keywords: fixed1.0.2 → verified1.0.2
Group: security
QA Contact: bsharma → benc
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: