fixed1.8.1, verified1.7.13, verified184.108.40.206
Assignee: nobody → dveditz
Component: Security → Security
Product: Firefox → Core
QA Contact: firefox → toolkit
I _think_ a correct patch for bug 327078 should fix this.... not sure, though. Triage note: This exploit allows an attacker to run arbitrary JS with chrome privileges even if the user has JS disabled....
Depends on: 327078
"continues to cause trouble" is a reference to similar bug 325991 which we thought fixed. This also hits aviary/moz17 hard, couldn't get 325991 to affect those.
Whiteboard: [sg:critical] chrome js execution even if JS disabled
Fixed on trunk, aviary, 1.7 by checkins for bug 327078.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Keywords: fixed-aviary1.0.8, fixed1.7.13
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9alpha
Fixed on 1.8 branches by checkins for bug 327078.
Keywords: fixed220.127.116.11, fixed1.8.1
Good question. I guess the issue is that you can detect print preview? Or rather detect anything that causes a binding reconstruct?
(In reply to comment #8) > Good question. I guess the issue is that you can detect print preview? Or > rather detect anything that causes a binding reconstruct? > i have some suspicious that your fix may not be very effective, though not sure. currently managed to kill the browser chrome on trunk (ff is building) by replacing it with the print preview one. btw, i am on irc irc.m.o now, though probably it is late your time.
the killing-chrome testcase seems to indicate regression. is it worth a new bug?
Yeah, that should be a separate bug, please. Sounds similar to what I described in bug 325991 comment 7 item 8.
Comment on attachment 213439 [details] html-killing-chrome-v1 (bug 328851) This testcase was spun into it's own bug 328851
Attachment #213438 - Attachment description: xbl-killing-chrome-v1 → xbl-killing-chrome-v1 (bug 328851)
Attachment #213439 - Attachment description: html-killing-chrome-v1 → html-killing-chrome-v1 (bug 328851)
verified with Windows afternoon respins of 0227 Mozilla 1.7.13 and Firefox 1.0.8
Keywords: fixed-aviary1.0.8, fixed1.7.13 → verified-aviary1.0.8, verified1.7.13
it is interesting to note that the exploit works with <xul:iframe> but *DOES NOT* work with <html:iframe>
> it is interesting to note that the exploit works with <xul:iframe> Yeah. XUL iframes start loads any time you mess with the layout object, whereas HTML ones do loads via the DOM node...
Marking [rft-dl] (ready for testing in Firefox 18.104.22.168 release candidates)
Whiteboard: [sg:critical] chrome js execution even if JS disabled → [sg:critical] chrome js execution even if JS disabled [rft-dl]
some random thoughts in case this "issue" gets linked from CVE(tm). needless to say, in my humble opinion, CVE/mitre are not very good in sikiurity. in addiotion, a mitre employee coauthored an RFC about "responsible disclosure" and was dumb enough to propose it to the ietf. the ietf replied something close to a word starting with F, containing U and ending in See-Key.
Marking this as verified based on verification comments and the length of time (over five years) since fix was taken.
You need to log in before you can comment on or make changes to this bug.