691014 - Firefox 3.6.X : Navigation away from a page with multiple active <select> dropdown menu can be used for Spoofing And ClickJacking with Java applet

Status: RESOLVED DUPLICATE of bug 575294

(Core :: DOM: Core & HTML, defect)

Description

[Jordi Chancel]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2
Build ID: 20110902133214

Steps to reproduce:

Like bug 575294 , Firefox shows the dropdown menu for <select> elements as an always-on-top chromeless window. It also allows arbitrary HTML content to be rendered in the <option> elements within the <select>.

This bug demonstrates than an attacker can cover a Java applet for evil.

I think this issue is critical.


Actual results:

A Java applet is spoofed by a clickjacking attack, using <select> elements with XUL.

Comment 1

[Jordi Chancel]

This testcase works with 1680 x 945 screen but an universal solution is possible.

Comment 2

[Jordi Chancel]

Attachment: ScreenShot

Comment 3

[Benjamin Smedberg]

Is the XUL necessary? Since we block remote XUL by default, an exploit that requires remote XUL is probably WONTFIX, but it doesn't look like this actually requires XUL to achieve the effect...

Is this really any different than bug 575294?

Comment 4

[Jordi Chancel]

no really different than bug 575294 but Jesse Ruderman want a new report for this issue with Java.

Comment 5

[Jordi Chancel]

like says Jesse Ruderman : it's likely to require a different fix (maybe even an API change between Firefox and Java).

Comment 6

[Daniel Veditz [:dveditz]]

if you can do this w/out XUL it looks sg:critical to me, if it requires XUL then it's probably sg:moderate at best.

Comment 8

[Jordi Chancel]

No update for Firefox 3.6.X ?
On Firefox 3.6.X it's a critical issue !

Comment 9

[Jordi Chancel]

I can do this without XUL but with only ONE <SELECT> element.
SG:CRITICAL?

Comment 10

[Jordi Chancel]

this <select> element can cover "X" and "Annuler" button!

Comment 11

[Jordi Chancel]

Let me know if you want a new testcase with only ONE <select> for covers "X" and "Annuler" button.

if you don't need a testcase : "sg:critical" ?

Comment 12

[Jesse Ruderman]

I'd like to see the new testcase.

Comment 13

[Jordi Chancel]

Finally without XUL this issue isn't credible...

This issue use XUL for make the <select> menu persist ! 

No update after Mozilla Firefox 3.6.23?

Comment 14

[Daniel Veditz [:dveditz]]

3.6.x is still supported for a while. I don't know when, but we're accepting security bugs for the bounty program until we announce it is end-of-life.

Comment 15

[Daniel Veditz [:dveditz]]

Similar to bug 575294, maybe something in that patch (in progress) will help here?

Comment 16

[Jordi Chancel]

UNCONFIRMED => NEW or ASSIGNED?

Comment 17

[Daniel Veditz [:dveditz]]

Olli: will a fix for bug 575294 also fix this case? Is there any special case we can use to detect the loss of focus to a non-Firefox dialog (or the Java dialog specifically) and kill the selects?

Comment 18

[Jordi Chancel]

JAVA have been updated, now the windows is always on top and visible BUT we can bypass it with setTimeout("window.moveTo(0,0)", 1900); on the Applet webpage for make unvisible the JAVA Windows!

I can sent you a new Proof Of Concept if you want.

Comment 19

[Jordi Chancel]

I've found a similare vulnerability that works on 10.0.1 without XUL.

https://bugzilla.mozilla.org/show_bug.cgi?id=726264

Comment 20

[Al Billings [:abillings - ex-MoCo]]

(In reply to Daniel Veditz [:dveditz] from comment #17)
> Olli: will a fix for bug 575294 also fix this case? Is there any special
> case we can use to detect the loss of focus to a non-Firefox dialog (or the
> Java dialog specifically) and kill the selects?

Olli, any comments on this?

Comment 21

[Josh Aas]

Since this particular bug requires XUL, which makes it not an issue past Firefox 3.6, and Firefox 3.6 is reaching EOL, marking this WONTFIX. I don't think we'll be backporting any potential fix for bug 575294.

Comment 22

[Jordi Chancel]

if this bug is publicly open, it's possible for an malicious hacker to use this information for code a exploit for firefox 14.0.1

Comment 23

[Daniel Veditz [:dveditz]]

Sorry for unhiding. I noticed bug 575294 was fixed but forgot to check which versions.

Comment 24

[Raymond Forbes[:rforbes]]

rforbes-bugspam-for-setting-that-bounty-flag-20130719

Comment 25

[Daniel Holbert [:dholbert]]

(In reply to Daniel Veditz [:dveditz] from comment #23)
> Sorry for unhiding. I noticed bug 575294 was fixed but forgot to check which
> versions.

This comment added "keep hidden while bug 575294 is" to whiteboard. Looks like bug 575294 was un-hidden just over a year ago. Can we un-hide this one (and related bug 726264) as well, now?