Last Comment Bug 690225 - (CVE-2011-3648) Universal XSS likely with MultiByte charset (e.g. japanese sites)
(CVE-2011-3648)
: Universal XSS likely with MultiByte charset (e.g. japanese sites)
Status: VERIFIED FIXED
[sg:high/moderate][qa!]
: verified-beta, verified1.9.2
Product: Core
Classification: Components
Component: Internationalization (show other bugs)
: unspecified
: All All
: -- normal with 1 vote (vote)
: mozilla10
Assigned To: Simon Montagu :smontagu
:
:
Mentors:
Depends on: 703868
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-28 20:56 PDT by Yosuke HASEGAWA
Modified: 2014-06-26 13:35 PDT (History)
14 users (show)
rforbes: sec‑bounty+
smontagu: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
fixed
fixed
.24-fixed


Attachments
HTML testcase (40 bytes, text/html; charset=shift_jis)
2011-10-04 02:56 PDT, Masatoshi Kimura [:emk]
no flags Details
Patch (1.80 KB, patch)
2011-10-11 03:56 PDT, Simon Montagu :smontagu
VYV03354: review-
Details | Diff | Splinter Review
mochitest (2.12 KB, patch)
2011-10-11 03:58 PDT, Simon Montagu :smontagu
no flags Details | Diff | Splinter Review
Testcase whose 2nd byte is in the valid range, but have no mappings (65 bytes, text/html; charset=shift_jis)
2011-10-11 07:15 PDT, Masatoshi Kimura [:emk]
no flags Details
Patch v.2 (2.01 KB, patch)
2011-10-12 01:52 PDT, Simon Montagu :smontagu
VYV03354: review+
Details | Diff | Splinter Review
More mochitests (6.80 KB, patch)
2011-10-18 05:25 PDT, Simon Montagu :smontagu
no flags Details | Diff | Splinter Review
0x81 0x20 testcase (297 bytes, text/html; charset=shift_jis)
2011-10-18 07:11 PDT, Masatoshi Kimura [:emk]
no flags Details
Adjust behaviour and tests from bug 116882 to be compatible with IE (4.24 KB, patch)
2011-10-18 15:00 PDT, Simon Montagu :smontagu
VYV03354: review+
Details | Diff | Splinter Review
Combined patch as checked in (4.60 KB, patch)
2011-10-18 23:03 PDT, Simon Montagu :smontagu
smontagu: review+
dveditz: approval‑mozilla‑aurora+
dveditz: approval‑mozilla‑beta+
dveditz: approval1.9.2.24+
smontagu: checkin+
Details | Diff | Splinter Review

Description Yosuke HASEGAWA 2011-09-28 20:56:20 PDT
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] 2011-10-04 02:56:00 PDT
Created attachment 564500 [details]
HTML testcase
Comment 2 Masatoshi Kimura [:emk] 2011-10-04 03:00:21 PDT
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] 2011-10-05 17:30:44 PDT
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 2011-10-11 03:56:42 PDT
Created attachment 566164 [details] [diff] [review]
Patch
Comment 5 Simon Montagu :smontagu 2011-10-11 03:58:38 PDT
Created attachment 566165 [details] [diff] [review]
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] 2011-10-11 07:13:21 PDT
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] 2011-10-11 07:15:29 PDT
Created attachment 566211 [details]
Testcase whose 2nd byte is in the valid range, but have no mappings
Comment 8 Simon Montagu :smontagu 2011-10-12 01:52:51 PDT
Created attachment 566465 [details] [diff] [review]
Patch v.2
Comment 10 Simon Montagu :smontagu 2011-10-18 05:25:33 PDT
Created attachment 567713 [details] [diff] [review]
More mochitests
Comment 11 Simon Montagu :smontagu 2011-10-18 05:27:58 PDT
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 2011-10-18 06:14:15 PDT
And backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/bfff1c1f8ed9 because it regressed bug 116882
Comment 13 Masatoshi Kimura [:emk] 2011-10-18 07:10:27 PDT
(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] 2011-10-18 07:11:53 PDT
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.
Comment 15 Simon Montagu :smontagu 2011-10-18 08:41:41 PDT
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] 2011-10-18 08:57:32 PDT
(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 2011-10-18 15:00:13 PDT
Created attachment 567895 [details] [diff] [review]
Adjust behaviour and tests from bug 116882 to be compatible with IE
Comment 18 Simon Montagu :smontagu 2011-10-18 23:03:55 PDT
Created attachment 567974 [details] [diff] [review]
Combined patch as checked in

Transferring r=emk.
Checked in: https://hg.mozilla.org/integration/mozilla-inbound/rev/1b656851fd53
Comment 19 Simon Montagu :smontagu 2011-10-19 03:08:34 PDT
https://hg.mozilla.org/mozilla-central/rev/1b656851fd53
Comment 20 Daniel Veditz [:dveditz] 2011-10-20 14:33:21 PDT
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 22 Simon Montagu :smontagu 2011-10-23 03:21:06 PDT
https://hg.mozilla.org/releases/mozilla-1.9.2/rev/f0e3833cdcea
Comment 23 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-10-26 09:29:45 PDT
qa+ for verification in Firefox 3.6.24, 8, and 9 using the attached PoC.
Comment 24 Al Billings [:abillings] 2011-10-31 14:44:10 PDT
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 2011-11-02 00:15:01 PDT
Does this issue have a CVE assigned, or will it be a last minute one?
Comment 27 Tony Chung [:tchung] 2011-12-04 23:43:40 PST
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] (way behind * queues, especially ni? queue) 2011-12-23 04:53:28 PST
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. annevankesteren+mozilla@gmail.com ?
Comment 29 Masatoshi Kimura [:emk] 2011-12-23 21:03:37 PST
Ok. Opera is the only browser which is vulnerable to this exploit now.
Comment 30 Anne (:annevk) 2012-01-03 05:27:15 PST
How is this exploit not present for 0x8F in euc-jp?
Comment 31 MustLive 2012-06-22 08:59:41 PDT
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] 2013-07-19 18:32:54 PDT
rforbes-bugspam-for-setting-that-bounty-flag-20130719

Note You need to log in before you can comment on or make changes to this bug.