Closed Bug 182078 Opened 22 years ago Closed 3 years ago

Discoverability of content-blanking to detect UI spoofing

Categories

(Core :: Security, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: morse, Unassigned)

Details

One solution to the UI-spoofing problem is to have a special keypress that will blank out all non-trusted parts of the screen display. See bug 22183 for details. Problem with such a solution is discoverability. The obvious thing would be to trigger the blanking by a menu item instead of by a keypress. But if the menu itself is spoofed, the attacker has control when you click on that menu item and he can chose to blank out whatever portion of the screen display he wants. Another solution would be to have a menu item that tells the user about the keypress. But then if the menu is spoofed, the atacker could have the menu item tell the user the wrong keypress and the spoofed page would capture that keypress and again decide what to blank out. So this is not going to be an easy problem to solve. Assigning to UE for ideas.
No longer depends on: 22183
reassigning to Patrice for consideration of UE ideas. I agree. This is a tough issue to resolve with a bullet proof solution.
Assignee: lorikaplan → patricec
Some ideas: * Special icon in the browser titlebar, click that and get a menu/whatever where you can blank content. The bad thing is that in some situations, on some OSes, you can spoof the titlebar (move window so that real titlebar is not visible, but spoofed is, for example). Full screen mode would also make you vulnerable to spoofing. * Have an icon in the OS toolbar, like on Windows we have the QuickLaunch icon if you have enabled that, and add a menu to blank content there. Again a page could spoof the toolbar in fullpage mode, although the spoofed toolbar would most likely look different.
OS: Windows NT → All
Hardware: PC → All
Keep in mind that I can always spoof a complete window, titlebar and all, by bringing up an image within the content area. Unlike a real window, this window could not be moved outside the original windows content area, so that would be a clue that it is a spoof. But if the user misses that, he could be fooled by the spoofed title bar and we've lost the game.
patricec is no longer working on this. we need to find a new owner if we think we can find a solution.. any ideas?
Assignee: patricec → heikki
This should IMHO be WONFIXed and made public. See bug 22183 comment 75 and bug 22183 comment 79.
Whiteboard: [sg:openended]
This bug is about a *potential solution* to a problem that is already public, so making this bug public.
Group: security
Whiteboard: [sg:openended] → [sg:investigate]
Whiteboard: [sg:investigate]
QA Contact: bsharma → toolkit

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

Assignee: hjtoi-bugzilla → nobody
Flags: needinfo?(dveditz)
Status: NEW → RESOLVED
Type: defect → enhancement
Closed: 3 years ago
Flags: needinfo?(dveditz)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.