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.

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

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?

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

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

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.

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

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

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

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" ?

I'd like to see the new testcase.

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?

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.

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

UNCONFIRMED => NEW or ASSIGNED?

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?

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.

I've found a similare vulnerability that works on 10.0.1 without XUL. https://bugzilla.mozilla.org/show_bug.cgi?id=726264

(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?

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.

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

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

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

(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?