"print preview" continues to cause trouble, allowing chrome privilege

VERIFIED FIXED in mozilla1.9alpha1

Status

()

Core
Security
VERIFIED FIXED
11 years ago
5 years ago

People

(Reporter: georgi - hopefully not receiving bugspam, Assigned: bz)

Tracking

({fixed1.8.1, verified1.7.13, verified1.8.0.2})

Trunk
mozilla1.9alpha1
x86
All
fixed1.8.1, verified1.7.13, verified1.8.0.2
Points:
---
Bug Flags:
blocking1.7.13 +
blocking-aviary1.0.8 +
blocking1.9a1 +
blocking1.8.1 +
blocking1.8.0.2 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:critical] chrome js execution even if JS disabled [rft-dl])

Attachments

(4 attachments)

"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.
Created attachment 213049 [details]
xblv1
Created attachment 213050 [details]
exploit ver1
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
Flags: blocking1.9a1?
Flags: blocking1.8.1?
Flags: blocking1.8.0.2?
Flags: blocking1.7.13?
Flags: blocking-aviary1.0.8?
"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
OS: Linux → All
Assignee: dveditz → bzbarsky
Fixed on trunk, aviary, 1.7 by checkins for bug 327078.
Status: NEW → RESOLVED
Last Resolved: 11 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: fixed1.8.0.2, fixed1.8.1
on trunk cvs the system principal seems fixed, but javascript may be still executed after closing print preview.

is this known/expected?
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.

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




Created attachment 213438 [details]
xbl-killing-chrome-v1 (bug 328851)
Created attachment 213439 [details]
html-killing-chrome-v1 (bug 328851)
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 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

11 years ago
Keywords: fixed1.8.0.2 → verified1.8.0.2
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.
Group: security
Marking this as verified based on verification comments and the length of time (over five years) since fix was taken.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.