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

Status: VERIFIED FIXED

(Core :: Security, defect)

Description

[georgi - hopefully not receiving bugspam]

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

Comment 1

[georgi - hopefully not receiving bugspam]

Attachment: xblv1

Comment 2

[georgi - hopefully not receiving bugspam]

Attachment: exploit ver1

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

Comment 4

[Daniel Veditz [:dveditz]]

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

Comment 5

[Boris Zbarsky [:bzbarsky]]

Fixed on trunk, aviary, 1.7 by checkins for bug 327078.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Fixed on 1.8 branches by checkins for bug 327078.

Comment 7

[georgi - hopefully not receiving bugspam]

on trunk cvs the system principal seems fixed, but javascript may be still executed after closing print preview.

is this known/expected?

Comment 8

[Boris Zbarsky [:bzbarsky]]

Good question.  I guess the issue is that you can detect print preview?  Or rather detect anything that causes a binding reconstruct?

Comment 9

[georgi - hopefully not receiving bugspam]

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

Comment 10

[georgi - hopefully not receiving bugspam]

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

Comment 11

[georgi - hopefully not receiving bugspam]

Attachment: xbl-killing-chrome-v1 (bug 328851)

Comment 12

[georgi - hopefully not receiving bugspam]

Attachment: html-killing-chrome-v1 (bug 328851)

Comment 13

[georgi - hopefully not receiving bugspam]

the killing-chrome testcase seems to indicate regression.

is it worth a new bug?

Comment 14

[Boris Zbarsky [:bzbarsky]]

Yeah, that should be a separate bug, please.  Sounds similar to what I described in bug 325991 comment 7 item 8.

Comment 15

[Daniel Veditz [:dveditz]]

Comment on attachment 213439 [details]
html-killing-chrome-v1 (bug 328851)

This testcase was spun into it's own bug 328851

Comment 16

[Tracy Walker [:tracy]]

verified with Windows afternoon respins of 0227
Mozilla 1.7.13 and Firefox 1.0.8

Comment 17

[georgi - hopefully not receiving bugspam]

it is interesting to note that the exploit works with <xul:iframe> but *DOES NOT* work with <html:iframe>

Comment 18

[Boris Zbarsky [:bzbarsky]]

> 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

[Dave Liebreich [:davel]]

Marking [rft-dl] (ready for testing in Firefox 1.5.0.2 release candidates)

Comment 20

[georgi - hopefully not receiving bugspam]

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.

Comment 21

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

Marking this as verified based on verification comments and the length of time (over five years) since fix was taken.