Bug 11725 - Netscape security preferences can be modified by webpages?
Netscape security preferences can be modified by webpages?
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: netscape (Show other bugs)
6.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-05-28 21:27 EDT by SB
Modified: 2014-03-16 22:14 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-05-31 18:34:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description SB 2000-05-28 21:27:22 EDT
The security button on the netscape navigation toolbar opens up the
security dialog where all netscape's security settings are held.  The
problem is that all those pages including the ones that deal with
encryption, cirtificates, and changing passwords are all html forms
written in javascript and use a form tag like this:
<FORM name=theform action=internal-dialog-handler method=post>

This is the actual form in the security prefernces window to set a
password:
<FORM name=theform action=internal-dialog-handler method=post>
<INPUT type="hidden" name="handle" value="03964930">
<INPUT type="hidden" name="xxxbuttonxxx">
<FONT size=2>
<TABLE><TR><TD><IMG align=left src=about:security?banner-secure></TD><TD>
<FONT face="Impress BT, Verdana, Arial, Helvetica, sans-serif"
point-size=16>
<B>Setting Up Your Communicator Password</B></FONT></TD></TR></TABLE>
<BR>It is strongly recommended that you protect your Private Key with a
Communicator password.  If you do not want a password, leave the password
field blank.<P>The safest passwords are at least 8 characters long, include
both letters and numbers, and contain no words from a dictionary.<P>
<TABLE><TR><TD>Password:</TD><TD>
<INPUT type=password name=password1></TD></TD></TR>
<TR><TD>Type it again to confirm:</TD><TD>
<INPUT type=password name=password2></TD><TD valign=bottom>
</TD></TR></TABLE>
<B>Important: Your password cannot be recovered.  If you forget it, you
will lose all of your certificates.</B><P>If you wish to change your
password or other security preferences, choose Security Info from the
Communicator menu.</FONT>
</FORM>

Look at the page I attached for another example of the number of things
that can possibly be changed without the user's knowledge.

The problem is, as far as I can tell this is true, netscape does NOT
restrict the use of such compenents in javascript interpreted on regular
webpages thereby allowing webpage operator's to change a user's security
setting by only making them submit a form!  This could have dire
consequences as things like encrytion can be turned off or lessened,
cirtificates could have passwords added unknown to the users, etc...etc..

Without the parent security window activated anything submitted to the
internal-dialog-handler causes netscape to bus errror in various places
most noteably, and common is the one shown in this gdb output:

(gdb) run
Starting program: /usr/lib/netscape/netscape-communicator

Program received signal SIGSEGV, Segmentation fault.
0x88523f3 in XP_HandleHTMLDialog ()
(gdb) where
#0  0x88523f3 in XP_HandleHTMLDialog ()
#1  0x83dbb5d in NET_GetURL ()
#2  0x82cda91 in fe_GetSecondaryURL ()
#3  0x82cd9fb in fe_GetURL ()
#4  0x8295c40 in XFE_SetFormElementToggle ()
#5  0x87b3f51 in ET_MakeHTMLAlert ()
#6  0x8932b56 in PR_HandleEvent ()
#7  0x8932ae3 in PR_ProcessPendingEvents ()
#8  0x82bda12 in FE_GetAcceptLanguage ()
#9  0x40047d15 in XtAppProcessEvent () from /usr/X11R6/lib/libXt.so.6
#10 0x82bcfdc in fe_EventLoop ()
#11 0x82bf9d5 in main ()
#12 0x40213c37 in __libc_start_main (main=0x82be1b4 <main>, argc=1,
argv=0xbffffc64, init=0x827f0c0 <_init>,
    fini=0x89467fc <_fini>, rtld_fini=0x4000c580 <_dl_fini>,
stack_end=0xbffffc5c) at ../sysdeps/generic/libc-start.c:90
(gdb)

This in the very least is a trivial DoS that can be annoying to the
millionth degree because javascript does not need to be enabled to
perform the dos or change the security setting (if it really is possible).

I cannot prove (yet) that it is possible for a webpage to change netscape's
security preferences, but from what my experimenting has shown, there is NO
restriction on what internal form components that webpages can use.  I will
continue to look into this further, but I am sure the potential is real and
is there, and that this is indeed a serious problem that needs to be dealt
with.  This needs to be looked into further by someone more familiar with
netscape's internals.

-Stan Bubrouski
Comment 1 Bill Nottingham 2000-05-31 18:34:02 EDT
Reported to netscape; we don''t have the netscape source
code, so we really can''t do anything about this.

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