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
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.
Treat invalid byte sequence correctly like as UTF-8.
in utf-8, "0xC2 0x22" is treated as 2 lettes, "(U+FFFD)(U+0022)".
Created attachment 564500 [details]
Confirming, not specific to JSON (probably charset converter problem).
Firefox 3.6 is also vulnerable.
Chrome and IE8/9.0.2 are not vulnerable.
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.
Created attachment 566164 [details] [diff] [review]
Created attachment 566165 [details] [diff] [review]
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 on attachment 566164 [details] [diff] [review]
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.
Created attachment 566211 [details]
Testcase whose 2nd byte is in the valid range, but have no mappings
Created attachment 566465 [details] [diff] [review]
Comment on attachment 566465 [details] [diff] [review]
Created attachment 567713 [details] [diff] [review]
Attachment 566165 [details] [diff] and attachment 567713 [details] [diff] [review] should be checked in as tests once this bug is opened.
And backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/bfff1c1f8ed9 because it regressed bug 116882
(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.
Created attachment 567738 [details]
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.
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].
(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.
Created attachment 567895 [details] [diff] [review]
Adjust behaviour and tests from bug 116882 to be compatible with IE
Created attachment 567974 [details] [diff] [review]
Combined patch as checked in
Checked in: https://hg.mozilla.org/integration/mozilla-inbound/rev/1b656851fd53
Comment on attachment 567974 [details] [diff] [review]
Combined patch as checked in
Approved for beta, aurora, and 22.214.171.124, a=dveditz for release-drivers/aurora/beta-triage
qa+ for verification in Firefox 3.6.24, 8, and 9 using the attached PoC.
Verified for 126.96.36.199 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52pre) Gecko/20111029 Namoroka/3.6.24pre (.NET CLR 3.5.30729) with first HTML test case and compared it against 184.108.40.206. This is fixed in 1.9.2.
Does this issue have a CVE assigned, or will it be a last minute one?
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
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. firstname.lastname@example.org ?
Ok. Opera is the only browser which is vulnerable to this exploit now.
How is this exploit not present for 0x8F in euc-jp?
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 220.127.116.11 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).