Last Comment Bug 163648 - URL with "vbscript:" protocol launches MS Internet Explorer
: URL with "vbscript:" protocol launches MS Internet Explorer
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Security (show other bugs)
: Trunk
: x86 Windows 2000
: P1 critical (vote)
: ---
Assigned To: Mitchell Stoltz (not reading bugmail)
: benc
Mentors:
: 172498 (view as bug list)
Depends on: 167475 noexternalprotocol 173010
Blocks: blackbird 1.2b
  Show dependency treegraph
 
Reported: 2002-08-20 07:38 PDT by Manko
Modified: 2006-03-12 17:00 PST (History)
16 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Demonstration (288 bytes, text/html)
2002-08-20 07:40 PDT, Manko
no flags Details
Another demonsrtation - when you click this link, 64 MSIE windows will pop up. Be carefully! (7.69 KB, text/html)
2002-08-21 00:10 PDT, Manko
no flags Details
Exploit - opening IE with redirection to any URL. (345 bytes, text/html)
2002-08-27 02:34 PDT, Manko
no flags Details
Patch - blacklist known dangerous protocols (2.88 KB, patch)
2002-10-08 16:41 PDT, Mitchell Stoltz (not reading bugmail)
dveditz: review+
darin.moz: superreview+
rjesup: approval+
Details | Diff | Review

Description Manko 2002-08-20 07:38:27 PDT
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:
Comment 1 Manko 2002-08-20 07:40:01 PDT
Created attachment 96016 [details]
Demonstration

Demonstration of exploit
Comment 2 Sebastian Biallas 2002-08-20 08:14:07 PDT
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...
Comment 3 Manko 2002-08-20 08:54:48 PDT
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.
Comment 4 Sebastian Biallas 2002-08-20 09:05:51 PDT
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.
Comment 5 Sander 2002-08-20 10:07:54 PDT
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.
Comment 6 Mihail Daskalov 2002-08-20 10:15:27 PDT
I don't see this behaviour with Build 2002081204 on Windows NT.
I have IE6 installed, but it is not invoked.
Comment 7 Manko 2002-08-21 00:10:41 PDT
Created attachment 96135 [details]
Another demonsrtation - when you click this link, 64 MSIE windows will pop up. Be carefully!

Exploit. Javascript can be turned off, this has no effect. You can get this
code even by e-mail.
Comment 8 Manko 2002-08-21 09:24:03 PDT
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
Comment 9 Sebastian Biallas 2002-08-21 11:56:50 PDT

*** This bug has been marked as a duplicate of 163767 ***
Comment 10 Jesse Ruderman 2002-08-22 11:45:04 PDT
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.
Comment 11 Jason Summers 2002-08-23 12:14:22 PDT
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).
Comment 12 Manko 2002-08-25 23:52:56 PDT
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
Comment 13 Manko 2002-08-26 00:30:16 PDT
All exploits run also in 1.0.1rc2 (build ID: 2002082306)
Comment 14 Manko 2002-08-26 01:51:14 PDT
Changing priority and target milestone - this bug must be resolved before 1.0.1
release.
Comment 15 Daniel Wang 2002-08-26 02:40:00 PDT
manko, don't do that.
see http://bugzilla.mozilla.org/queryhelp.cgi#severity

is this a networking or security bug?
Comment 16 Manko 2002-08-26 03:02:41 PDT
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.
Comment 17 Manko 2002-08-27 02:34:03 PDT
Created attachment 96821 [details]
Exploit - opening IE with redirection to any URL.

Idea by Jason Summers.
Comment 18 Manko 2002-08-27 02:37:30 PDT
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.
Comment 19 Daniel Veditz [:dveditz] 2002-08-28 09:17:38 PDT
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.
Comment 20 georgi - hopefully not receiving bugspam 2002-08-29 02:28:22 PDT
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.
Comment 21 Manko 2002-08-29 08:43:25 PDT
Does latest Netscape 7 have this bug? If yes, it's very sadly...
Comment 22 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2002-08-29 13:02:22 PDT
Yeah, we should pop up a confirmation dialog for external protocol handlers just
like we do with external helper applications.
Comment 23 Sven Krohlas 2002-08-29 13:27:15 PDT
@ 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... :(
Comment 24 Manko 2002-08-29 23:56:46 PDT
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.
Comment 25 Manko 2002-08-30 00:07:38 PDT
Adding Ben to demonstrate him dangerous effect of external protocols without
opening a new bug.
Comment 26 Manko 2002-09-11 03:02:27 PDT
Also persists in Mozilla 1.0.1
Comment 27 Jesse Ruderman 2002-09-11 16:53:16 PDT
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.
Comment 28 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2002-09-11 19:17:32 PDT
Why don't we treat external protocol handlers exactly the same as external
helper apps, which pop up a dialog by default?
Comment 29 Manko 2002-09-12 01:52:20 PDT
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.
Comment 30 georgi - hopefully not receiving bugspam 2002-09-12 04:41:28 PDT
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 :)


Comment 31 Manko 2002-09-12 04:50:20 PDT
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.
Comment 32 georgi - hopefully not receiving bugspam 2002-09-12 05:04:26 PDT
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.
Comment 33 Manko 2002-09-12 05:15:56 PDT
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?
Comment 34 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2002-09-12 05:52:24 PDT
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.
Comment 35 Jesse Ruderman 2002-09-15 21:23:34 PDT
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.
Comment 36 georgi - hopefully not receiving bugspam 2002-09-16 03:21:44 PDT
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" ?



Comment 37 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2002-09-16 07:48:15 PDT
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.
Comment 38 [:jesup] on pto until 2016/7/5 Randell Jesup 2002-09-20 12:44:36 PDT
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.

Comment 39 [:jesup] on pto until 2016/7/5 Randell Jesup 2002-09-20 12:46:55 PDT
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)
Comment 40 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2002-09-20 12:54:33 PDT
This is a blocker for 1.2beta.
Comment 41 Daniel Veditz [:dveditz] 2002-09-26 13:55:27 PDT
adt wants this, but we need to see a branch patch to approve.
Comment 42 Jesse Ruderman 2002-09-30 20:18:31 PDT
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?
Comment 43 georgi - hopefully not receiving bugspam 2002-10-01 02:46:37 PDT
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.
Comment 44 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2002-10-01 04:47:42 PDT
> > 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.
Comment 45 Manko 2002-10-01 06:11:54 PDT
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.
Comment 46 Michael Buckland 2002-10-03 11:05:27 PDT
Echoing dveditz, adt wants this, but we need to see a patch.
Comment 47 Bradley Baetz (:bbaetz) 2002-10-03 20:25:16 PDT
Also see bug 172498..
Comment 48 georgi - hopefully not receiving bugspam 2002-10-04 02:26:50 PDT
Comment #8 shows approximately when the bug get introduced.
What about removing the checkin that introduced the bug?
Comment 49 Manko 2002-10-04 03:42:16 PDT
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.
Comment 50 Manko 2002-10-08 09:19:18 PDT
I have entered bug 173010 for discussions about whitelist.
Comment 51 Dave Barrowman 2002-10-08 11:07:37 PDT
CCing myself & Evelyn Prime MacAdam.
Comment 52 Mitchell Stoltz (not reading bugmail) 2002-10-08 16:41:43 PDT
Created attachment 102263 [details] [diff] [review]
Patch - blacklist known dangerous protocols

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 53 Darin Fisher 2002-10-08 16:46:50 PDT
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).
Comment 54 Daniel Veditz [:dveditz] 2002-10-08 17:07:17 PDT
Comment on attachment 102263 [details] [diff] [review]
Patch - blacklist known dangerous protocols

sr=dveditz
Comment 55 Manko 2002-10-09 00:47:05 PDT
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 56 [:jesup] on pto until 2016/7/5 Randell Jesup 2002-10-09 08:37:03 PDT
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.
Comment 57 Daniel Veditz [:dveditz] 2002-10-09 09:43:19 PDT
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.
Comment 58 Daniel Veditz [:dveditz] 2002-10-09 09:44:20 PDT
*** Bug 172498 has been marked as a duplicate of this bug. ***
Comment 59 Mitchell Stoltz (not reading bugmail) 2002-10-10 17:13:43 PDT
Fix checked in on trunk and 1.0 branch, adding fixed1.0.2.
Comment 60 bsharma 2002-10-11 14:56:27 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.