423389 - UTF-7 charset inheritance via data URI

Status: RESOLVED INVALID

(Core :: Internationalization, defect)

Description

[Mario Heiderich]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.12) Gecko/20080207 Ubuntu/7.10 (gutsy) Firefox/2.0.0.12
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.12) Gecko/20080207 Ubuntu/7.10 (gutsy) Firefox/2.0.0.12

Charset inheritance has been fixed in FF 2.0.0.12 but it still works in all current versions if performed via UTF-7 flagged data URI. This means in particular that XSS can be performed on any given page without a META tag and a charset field in the server response headers.

I created a PoC to test on - other browsers like IE6-8 still suffer from charset inheritance w/o data URI - which can be seen in the second example link.

1st: http://mario.heideri.ch/framed.php
2nd: http://mario.heideri.ch/test.html

P.S.: It might be necessary to refresh the first example several times before it executes - this is caused by an issue in NoScript which has been fixed already.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Uh.... I don't see the problem.  We disabled charset inheritance across hosts, but the subframe is on the same host here, no?

Comment 2

[Giorgio Maone [:ma1]]

http://evil.hackademix.net/utf7/

Comment 3

[Boris Zbarsky [:bzbarsky]]

Odd.  Well, that looks pretty similar to that other UTF-7 bug.  Like I said there, someone needs to disassemble this whole Netscape-era mess and reassemble it in a sane way...

Comment 4

[Mario Heiderich]

Thx for the PoC, Giorgio - I was just about creating a similar file but you were faster ;) 

IE 5.5-8 suffer from the same problems - at least when not dealing with data URIs.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Oh, for what it's worth, I don't see this problem on trunk...

Comment 6

[Giorgio Maone [:ma1]]

Weird, because I tested my URL on on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031605 Minefield/3.0b5pre before posting it and it still works...

Comment 7

[Mario Heiderich]

I just reproduced with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008020507 Firefox/3.0b3pre if that info is of any use.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Very odd... You were testing in a newly-started browser, etc, right?

I definitely can't reproduce in a debug build (Firefox or Seamonkey).  Nor in a 2008-03-16 Seamonkey nightly.  This is all on Linux.

I could reproduce with the older build I use for browsing, but it's pretty old.  I'm working on getting an up-to-date branch build right now.

Comment 9

[Giorgio Maone [:ma1]]

Ouch, I think we saw some cache effect here. 
I can't reproduce the cross-site case (which I tested on a clean profile) after cleaning the cache. 
Obviously the inner frame was cached from Mario's original PoC.
Sorry for the false alarm, looks like  just a same-site inheritance.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Ah.  Yeah, same-site this is expected behavior.

Comment 11

[Giorgio Maone [:ma1]]

Resolving as INVALID per comment #10. 
Mario, please reopen if you find any evidence of cross-site scripting danger from this behavior, thanks.

Comment 12

[Mario Heiderich]

Ah okay ;) Nevermind. @Giorgio: Let's write MS next...

Comment 13

[Daniel Veditz [:dveditz]]

Can this bug be unhidden now, or is there an IE issue we need to keep quiet until it's addressed?