Closed
Bug 328469
Opened 19 years ago
Closed 19 years ago
"print preview" continues to cause trouble, allowing chrome privilege
Categories
(Core :: Security, defect)
Tracking
()
VERIFIED
FIXED
mozilla1.9alpha1
People
(Reporter: guninski, Assigned: bzbarsky)
References
Details
(Keywords: fixed1.8.1, verified1.7.13, verified1.8.0.2, Whiteboard: [sg:critical] chrome js execution even if JS disabled [rft-dl])
Attachments
(4 files)
"print preview" continues to cause trouble, allowing chrome privilege
"print preview" continues to cause trouble via xbl and <xul:iframe>
(not quite sure whether xbl is needed).
works with javascript *disabled*
testcase to follow.
Reporter | ||
Comment 1•19 years ago
|
||
Reporter | ||
Comment 2•19 years ago
|
||
Assignee | ||
Updated•19 years ago
|
Assignee: nobody → dveditz
Product: Firefox → Core
QA Contact: firefox → toolkit
Assignee | ||
Comment 3•19 years ago
|
||
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
Flags: blocking1.9a1?
Flags: blocking1.8.1?
Flags: blocking1.8.0.2?
Flags: blocking1.7.13?
Flags: blocking-aviary1.0.8?
Comment 4•19 years ago
|
||
"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.
Flags: blocking1.9a1?
Flags: blocking1.9a1+
Flags: blocking1.8.1?
Flags: blocking1.8.1+
Flags: blocking1.8.0.2?
Flags: blocking1.8.0.2+
Flags: blocking1.7.13?
Flags: blocking1.7.13+
Flags: blocking-aviary1.0.8?
Flags: blocking-aviary1.0.8+
Whiteboard: [sg:critical] chrome js execution even if JS disabled
Updated•19 years ago
|
OS: Linux → All
Assignee | ||
Updated•19 years ago
|
Assignee: dveditz → bzbarsky
Assignee | ||
Comment 5•19 years ago
|
||
Fixed on trunk, aviary, 1.7 by checkins for bug 327078.
Status: NEW → RESOLVED
Closed: 19 years ago
Keywords: fixed-aviary1.0.8,
fixed1.7.13
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9alpha
Assignee | ||
Comment 6•19 years ago
|
||
Fixed on 1.8 branches by checkins for bug 327078.
Keywords: fixed1.8.0.2,
fixed1.8.1
Reporter | ||
Comment 7•19 years ago
|
||
on trunk cvs the system principal seems fixed, but javascript may be still executed after closing print preview.
is this known/expected?
Assignee | ||
Comment 8•19 years ago
|
||
Good question. I guess the issue is that you can detect print preview? Or rather detect anything that causes a binding reconstruct?
Reporter | ||
Comment 9•19 years ago
|
||
(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.
Reporter | ||
Comment 10•19 years ago
|
||
(In reply to comment #7)
> but javascript may be still
> executed after closing print preview.
>
on second thought i am not sure the js is executed in print preview, but there are some strangenesses with print preview.
testcase that kills the browser chrome and replace it with print preview to follow.
besides there is potential memory corruption that is investigated.
Reporter | ||
Comment 11•19 years ago
|
||
Reporter | ||
Comment 12•19 years ago
|
||
Reporter | ||
Comment 13•19 years ago
|
||
the killing-chrome testcase seems to indicate regression.
is it worth a new bug?
Assignee | ||
Comment 14•19 years ago
|
||
Yeah, that should be a separate bug, please. Sounds similar to what I described in bug 325991 comment 7 item 8.
Comment 15•19 years ago
|
||
Comment on attachment 213439 [details]
html-killing-chrome-v1 (bug 328851)
This testcase was spun into it's own bug 328851
Updated•19 years ago
|
Attachment #213438 -
Attachment description: xbl-killing-chrome-v1 → xbl-killing-chrome-v1 (bug 328851)
Updated•19 years ago
|
Attachment #213439 -
Attachment description: html-killing-chrome-v1 → html-killing-chrome-v1 (bug 328851)
Comment 16•19 years ago
|
||
verified with Windows afternoon respins of 0227
Mozilla 1.7.13 and Firefox 1.0.8
Reporter | ||
Comment 17•19 years ago
|
||
it is interesting to note that the exploit works with <xul:iframe> but *DOES NOT* work with <html:iframe>
Assignee | ||
Comment 18•19 years ago
|
||
> 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...
Comment 19•19 years ago
|
||
Marking [rft-dl] (ready for testing in Firefox 1.5.0.2 release candidates)
Whiteboard: [sg:critical] chrome js execution even if JS disabled → [sg:critical] chrome js execution even if JS disabled [rft-dl]
Updated•19 years ago
|
Keywords: fixed1.8.0.2 → verified1.8.0.2
Reporter | ||
Comment 20•19 years ago
|
||
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.
Updated•19 years ago
|
Group: security
Comment 21•13 years ago
|
||
Marking this as verified based on verification comments and the length of time (over five years) since fix was taken.
Updated•13 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•