690225 - (CVE-2011-3648) Universal XSS likely with MultiByte charset (e.g. japanese sites)

Status: VERIFIED FIXED

(Core :: Internationalization, defect)

Description

[Yosuke HASEGAWA]

User Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0) Gecko/20100101 Firefox/7.0
Build ID: 20110916091512

Steps to reproduce:

JSON containing broken MBCS sequence allows hijacking by attacker.
Attacker can read the secret contents of JSON across the domain if attacker can control some field in it.

PoC is here: http://utf-8.jp/PoC/mbcs-json.html




Actual results:

Byte sequence "0x82 0x22" is invalid for Shift_JIS.
therefore, it should be treated as 2 letters, such as "(U+FFFD)(U+0022)"
but Firefox treats it as 1 letter so double quote trailing invalid lead byte is vanished.



Expected results:

Treat invalid byte sequence correctly like as UTF-8.
in utf-8, "0xC2 0x22" is treated as 2 lettes, "(U+FFFD)(U+0022)".

Comment 1

[Masatoshi Kimura [:emk]]

Attachment: HTML testcase

Comment 2

[Masatoshi Kimura [:emk]]

Confirming, not specific to JSON (probably charset converter problem).
Firefox 3.6 is also vulnerable.
Chrome and IE8/9.0.2 are not vulnerable.

Comment 3

[Daniel Veditz [:dveditz]]

Unless sites are validating their input down to the level of valid shift-jis (or similar) sequences this bug likely makes many of them vulnerable to XSS.

Comment 4

[Simon Montagu :smontagu]

Attachment: Patch

Comment 5

[Simon Montagu :smontagu]

Attachment: mochitest

The patch fixes the Shift_JIS case, and it looks from code inspection that EUC_JP doesn't have this vulerability, but I'll add tests for other multibyte character sets as well.

Comment 6

[Masatoshi Kimura [:emk]]

Comment on attachment 566164 [details] [diff] [review]
Patch

The second byte should be unconsumed only when it is not in the valid Shift_JIS 2nd byte range (that is, 40-7F,80-FC) to match the IE/Chrome behavior.

Comment 7

[Masatoshi Kimura [:emk]]

Attachment: Testcase whose 2nd byte is in the valid range, but have no mappings

Comment 8

[Simon Montagu :smontagu]

Attachment: Patch v.2

Comment 9

[Simon Montagu :smontagu]

Comment on attachment 566465 [details] [diff] [review]
Patch v.2

https://hg.mozilla.org/integration/mozilla-inbound/rev/308f180eb3f4

Comment 10

[Simon Montagu :smontagu]

Attachment: More mochitests

Comment 11

[Simon Montagu :smontagu]

Attachment 566165 [details] [diff] and attachment 567713 [details] [diff] [review] should be checked in as tests once this bug is opened.

Comment 12

[Simon Montagu :smontagu]

And backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/bfff1c1f8ed9 because it regressed bug 116882

Comment 13

[Masatoshi Kimura [:emk]]

(In reply to Simon Montagu from comment #12)
> And backed out in
> https://hg.mozilla.org/integration/mozilla-inbound/rev/bfff1c1f8ed9 because
> it regressed bug 116882

It means IE was vulnerable to Universal XSS.

Comment 14

[Masatoshi Kimura [:emk]]

Attachment: 0x81 0x20 testcase

Results of the testcase on various browsers:
IE 8 (with MS11-057), IE 9.0.3: %u7E3A%uFFFD%20abc / %u7E3A%uFFFD%20abc
Chrome and Safari 5.1.1: %u7E3A / %u7E3A%1A%20abc
Opera 11.51: %u7E3A%uFFFDabc / %u7E3A%uFFFDabc (Oh, Opera is still vulnerable)

No latest browsers display 0x81 0x20 as a middle dot.
Moreover, the URL of bug 116882 is dead. I don't think we need to sacrifice security for compatibility with such an ancient web page. I propose removing test_bug116882.js.

Comment 15

[Simon Montagu :smontagu]

Does IE convert to middle dot in the case where both bytes are in the valid range, but there is no mapping? Opera and Chrome both display 0xFFFD in attachment 566211 [details].

Comment 16

[Masatoshi Kimura [:emk]]

(In reply to Simon Montagu from comment #15)
> Does IE convert to middle dot in the case where both bytes are in the valid
> range, but there is no mapping? Opera and Chrome both display 0xFFFD in
> attachment 566211 [details].
IE displays U+30FB in this case.

Comment 17

[Simon Montagu :smontagu]

Attachment: Adjust behaviour and tests from bug 116882 to be compatible with IE

Comment 18

[Simon Montagu :smontagu]

Attachment: Combined patch as checked in

Transferring r=emk.
Checked in: https://hg.mozilla.org/integration/mozilla-inbound/rev/1b656851fd53

Comment 19

[Simon Montagu :smontagu]

https://hg.mozilla.org/mozilla-central/rev/1b656851fd53

Comment 20

[Daniel Veditz [:dveditz]]

Comment on attachment 567974 [details] [diff] [review]
Combined patch as checked in

Approved for beta, aurora, and 1.9.2.24, a=dveditz for release-drivers/aurora/beta-triage

Comment 21

[Simon Montagu :smontagu]

https://hg.mozilla.org/releases/mozilla-aurora/rev/10dca99e30c4
https://hg.mozilla.org/releases/mozilla-beta/rev/952cab8d5ff7

Comment 22

[Simon Montagu :smontagu]

https://hg.mozilla.org/releases/mozilla-1.9.2/rev/f0e3833cdcea

Comment 23

[u279076]

qa+ for verification in Firefox 3.6.24, 8, and 9 using the attached PoC.

Comment 24

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

Verified for 1.9.2.24 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.24pre) Gecko/20111029 Namoroka/3.6.24pre (.NET CLR 3.5.30729) with first HTML test case and compared it against 1.9.2.23. This is fixed in 1.9.2.

Comment 25

[Huzaifa Sidhpurwala]

Does this issue have a CVE assigned, or will it be a last minute one?

Comment 27

[Tony Chung [:tchung]]

Verified fix on 9.0beta 4. :  Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20100101 Firefox/9.0, branch GECKO90_2011113005_RELBRANCH. 

per comment 14, 9b4 shows: %u7E3A%uFFFD%20abc / %u7E3A%uFFFD%20abc

Comment 28

[Olli Pettay [:smaug][[e-mail]]]

Is this bug a problem in other browsers?

Anne (from Opera) was spec'ing something related to this, and noticed that Gecko's
behavior had changed.
Would it be ok to CC him. [e-mail] ?

Comment 29

[Masatoshi Kimura [:emk]]

Ok. Opera is the only browser which is vulnerable to this exploit now.

Comment 30

[Anne (:annevk)]

How is this exploit not present for 0x8F in euc-jp?

Comment 31

[MustLive]

Guys!

I'll remind you concerning vulnerabilities about which I informed you by e-mail at beginning of March 2009. That time I've informed you about XSS attacks via charsets EUC-JP and SHIFT_JIS, and also about Charset Remembering attack, which can be used for making persistent attacks via different charsets, which allow to conduct XSS attacks. I.e. Yosuke wrote you about the same issue (just only about one from two charsets) 2.5 years after me. And Cheng Peng Su wrote about these and other charsets concerning Firefox 1.5.0.6 in his article at 7th of August 2006.

But you have ignored and not fixed those vulnerabilities in your browsers. And later, in MFSA 2011-47 Mozilla fixed possibilities of XSS attacks via charset Shift-JIS, about which I've informed you in March 2009 (but still not fixed the same issue with charset EUC-JP). So first you have ignored my letter and publication at 3rd of March 2009 about these issues (http://websecurity.com.ua/2928/), and only after 2,5 years, at 8th of November 2011, you have fixed one from few vulnerabilities informed by me.

Note, that I've already sent the letter to Mozilla with new information about XSS attacks via multiple charsets (it concerns Firefox, Internet Explorer and Opera).

Comment 32

[Raymond Forbes[:rforbes]]

rforbes-bugspam-for-setting-that-bounty-flag-20130719