47777 - Browser dialogs should not be mimicable

Status: RESOLVED WONTFIX

(Core :: XUL, defect, P3)

Description

[Suresh Duddi (gone)]

Dialogs generated by features in the browser like the save password, master
password etc should have chrome that cannot be ever duplicated. It is a secutiry
violation otherwise.

Comment 1

[Suresh Duddi (gone)]

Nominating for nsbeta3. Ccing jar (aging security expert).

Comment 2

[Stephen P. Morse]

How do we make dialog chromes be unduplicatable?

Comment 3

[Ben Goodger (use ben at mozilla dot org for email)]

IE4 allows remote sites to open native looking dialogs without the client edge. 
They append '-- Web Page Dialog' to the dialog title however. 

See:
http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/showmodaldialo
g.asp

We could also add a security indication at the bottom of the dialog, although 
implementing that is probably more complicated. 

Preventing someone from making native looking chrome is impossible, and indeed 
undesirable (we want to promote the creation of remote client/server 
applications) 

Over to XPToolkit... I think the -- Web Page Dialog is a good start (similar to 
the 'JavaScript Alert' days of yore) 

Comment 4

[Jim Roskind]

There really is no way to prevent simulating a dialog.  In the extreme, any code
that can put out pixels on a graphical context can "draw" something that looks
exactly the way any dialog looks.  The only restriction is that the dialog
cannot be "dragged" beyond the extent of the underlying graphical context.  Most
users don't ever bother to drag a dialog before filling it out... so even
supporting dragging within the context is not necessary for a spoof.

IF we want the opportunity to allow a user to have un-spoofable dialogs, we have
to have either a reserved portion of realestate (we would always put the dialog
in a special place that was not writable by unprivledged code), or have a
reserved time (we would only ask for the master password at startup), or have a
reserved keystroke sequence that standard code could not intercept (like the way
NT always requires entering ctrl-alt-delete before supplying a password).

For most users, this is overkill, and will rarely be used or desired... but it
wouldn't hurt to have some option for the security paranoid folks.

Comment 5

[Peter Trudelle]

I'm not hearing a critical need for this, nor a viable means for XPToolkit to
accomplish the general case in the next few weeks. Should we just append/prepend
some text to other window titles?  Mitch, do you have any comments?
cc jrgm

Comment 6

[Jim Roskind]

We had text around Java windows for a while in the old days.  The first text was:
Untrusted Java Window
The banks *hated* this, and a few revs later we changed it to:
Unsigned Java Window
as a compromise.  Then we noticed that JS was supporting chromeless windows...
and eventually, when yet another bug hit us, I think we just discarded the text
completely.
"History forgotten is doomed to be repeated" 

Comment 7

[Mitchell Stoltz (not reading bugmail)]

I would argue this should be a lower priority than other kinds of exploits, 
simply because, as Jar has pointed out, there's no easy way to deal with it.

Comment 8

[Peter Trudelle]

Okay, since we only have two priorities we'll have to come back to this in a
future release.  nsbeta3-, cc jrgm in case he disagrees.

Comment 9

[Jesse Ruderman]

These three bugs are related:
bug 31573 Javascript alerts, confirms should be marked as such
bug 47777 Browser dialogs should not be mimicable
bug 64676 JavaScript Prompt could be confused for system dialog

Comment 10

[Robin Green]

I believe an optional and configurable, untrappable key combination (like
Windows' CTRL+ALT+DEL) would be a simple and effective way to secure one of the
most important dialogs - the master password dialog. If you keyed the key
combination at the wrong time, mozilla could display a dialog box warning about
spoof dialogs.

Comment 11

[Glenn Linderman]

As comment #4 points out, there really is no way to prevent simulating a dialog.

However, users should never be prompted for password asynchronously a dialog box that is presented to accept the password. This is always susceptible to Trojans.

Rather, the user should be informed of the need to enter a password, possibly
via a dialog box, but preferably some other way (flashing window bar that says
"need password to continue"?) and then take appropriate action using the
facilities of the application to supply a password.

For browsers, this would having a password entry spot always visible, or a
button or menu entry to request a password entry dialog, in the "chrome" (I
think it is called) of Firefox.  Such a box would be used to respond to the
request for password, if and when the user chooses to respond.

I guess that solution wouldn't necessarily work for "kiosk" mode, but then
again sites accessed via kiosk mode should request passwords ahead of time, via
login forms, rather than using the "password protection" feature of the web
server to cause an asynchronous request for password.

This issue seems to be the same as, or similar to, bug 101611

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:enndeakin, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 13

[Neil Deakin]

Not much to do here.