(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #311802 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=311802 Imported into Bugzilla on 06/27/00 11:23) Submitter name: Patrik Nilsson Submitter email address: patrik@patrik.com Product: Communicator 4.x Operating system: Windows 95 OS version: any Issue summary: Stealing Certificate DB password through javascript dialogs. Issue details: Using javascript, it's possible to construct dialog boxes that are very hard to distinguish from Communicators internal ones. This can be used to embed a dialog box in a web page that looks like the Certificate DB dialog box, making it possible to trick people into disclosing their Certificate DB passwords. A simple example can be found at: http://www.patrik.com/sneak/ Patrik Additional computer info: Acknowledgement checkbox: on This bug was submitted with Mozilla/4.5b1 [en] (WinNT; I). ------- Additional Comments From leger 08/07/98 10:06 ------- Setting blank component to security. Setting TFV to 4.5b2 ------- Additional Comments From paulmac 03/30/1999 11:41 ------- Moving all Security TFV 5.0 bugs to TFV 5.0 SF1in in preparation for moving them to Bugzilla (per leger) ------- Additional Comments From lord Jun-05-1999 22:06 ------- Moving to Cartman. We should make sure the Cartman UI is hard to spoof. ------- Additional Comments From ddrinan Aug-18-1999 18:39 ------- Mass targeting to M12. ------- Additional Comments From ddrinan May-15-2000 10:56 ------- Assigning all mwelch bugs to ddrinan. ------- Additional Comments From ddrinan Jun-26-2000 13:33 ------- Assigning this bug to clayton. We need some way in Mozilla to display non-spoofable chrome.

Triaging clayton's bug list... Re-assigning this to Mitch Stoltz. Ccing Patrick Beard, David Hyatt, Ben Goodger.

Hmm, yes, this problem is hairy. In the brave new Mozilla world, it seems that no piece of screen or window real estate is unspoofable. Should we do like Java and put a warning bar on the bottom of every window created by web scripts? Or is there a more elegant solution?

the example given appears to use LAYERs to create lookalike dialogs. I'm sure someone could come up with a pixel perfect look too... this is entirely possible in 4.x, and in Mozilla. There's nothing new or special about this ability, and it seems it'd be impossible to detect or prevent either.

It is/was a waste to put bars of text at the bottom of each web-generated window. The attacker work-around is to use the graphical context to display something that *looks* just like a dialog box on top of the context :-/. Most folks don't try to drag a dialog before typing, so they would have no way to detect this attack. In 4.x this attack was demonstrated *including* support for dragging the "simulated" pop-up dialog, so long as the dragging didn't go "too" far (re: off the graphical context). There is no nice work around given our current approach. The traditional two methods are a) reserved real estate; b) reserved key strokes (example: Win NT uses ctrl-alt-del). We can really support neither. We have always faced this problem. One possible approach is to try to use temporal separation, and have the passwords entered *only* as the app is first coming up, rather than "as needed." Although the spoofing may look a little better with mozilla, this is really a known problem that has been with us a long time.

QA to czhang

This is awful! Isn't there something that can be done, at least in this specific case? AOL uses a special icon to distinguish its orriginal mail from spoofers. How about a special icon for the control menu (in Windows) or a special "authentic" icon in the status bar of dialogs similar to the lock for SSL. Although this wouldn't fix the case in which an image of the entire dialog is embedded in a page, it'll at least stop hackers from generating false Mozilla dialogs.

No matter how we structure our program, some clever attacker can always write a program that simulates whatever we attempt to keep exclusive to our own program. This is the risk we take in letting our browser run untrusted code. A Java applet can be written that makes it look like your Macintosh has crashed, and naive users will assume that Mozilla caused the crash. On the AOL service, there are many examples where folks send out URLs to fake web pages that use graphics stolen from AOL's official sites, and encourage people to enter their AOL account passwords. I don't know how successful these are, but clearly they work well enough to warrant there continued attempts. How could we prevent those kinds of attacks?

Mass changing QA to ckritzer.

*** This bug has been marked as a duplicate of 64676 ***

We can't prevent spoofing, but we should probably make it harder by putting some sort of notice on the window. That's covered in 64676.

Verified DUPLICATE on: MacOS90 2001-02-13-04-Mtrunk LinRH62 2001-02-13-06-Mtrunk MOZILLA Win98SE 2001-02-13-06-Mtrunk