Note: There are a few cases of duplicates in user autocompletion which are being worked on.
Bug 690225 (CVE-2011-3648)

Universal XSS likely with MultiByte charset (e.g. japanese sites)

VERIFIED FIXED in Firefox 8

Status

()

Core
Internationalization
VERIFIED FIXED
6 years ago
3 years ago

People

(Reporter: Yosuke HASEGAWA, Assigned: smontagu)

Tracking

(Depends on: 1 bug, {verified-beta, verified1.9.2})

unspecified
mozilla10
verified-beta, verified1.9.2
Points:
---
Bug Flags:
sec-bounty +
in-testsuite ?

Firefox Tracking Flags

(firefox8 fixed, firefox9 fixed, status1.9.2 .24-fixed)

Details

(Whiteboard: [sg:high/moderate][qa!])

Attachments

(6 attachments, 3 obsolete attachments)

(Reporter)

Description

6 years ago
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)".
(Reporter)

Updated

6 years ago
Component: QuickLaunch (AKA turbo mode) → JavaScript Engine
Created attachment 564500 [details]
HTML testcase
Attachment #564500 - Attachment mime type: text/html → text/html; charset=shift_jis
Confirming, not specific to JSON (probably charset converter problem).
Firefox 3.6 is also vulnerable.
Chrome and IE8/9.0.2 are not vulnerable.
Assignee: nobody → smontagu
Status: UNCONFIRMED → NEW
Component: JavaScript Engine → Internationalization
Ever confirmed: true
OS: Windows Vista → All
QA Contact: quicklaunch → i18n
Hardware: x86 → All
Version: 7 Branch → unspecified
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.
Summary: JSON hijacking with MultiByte charset → Universal XSS likely with MultiByte charset (e.g. japanese sites)
Whiteboard: [sg:high/moderate]
(Assignee)

Comment 4

6 years ago
Created attachment 566164 [details] [diff] [review]
Patch
Attachment #566164 - Flags: review?(VYV03354)
(Assignee)

Comment 5

6 years ago
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 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.
Attachment #566164 - Flags: review?(VYV03354) → review-
Created attachment 566211 [details]
Testcase whose 2nd byte is in the valid range, but have no mappings
(Assignee)

Updated

6 years ago
Attachment #566211 - Attachment mime type: text/html → text/html; charset=shift_jis
(Assignee)

Comment 8

6 years ago
Created attachment 566465 [details] [diff] [review]
Patch v.2
Attachment #566465 - Flags: review?(VYV03354)
(Assignee)

Updated

6 years ago
Attachment #566164 - Attachment is obsolete: true
Attachment #566465 - Flags: review?(VYV03354) → review+
(Assignee)

Comment 9

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

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

Updated

6 years ago
Target Milestone: --- → mozilla10
(Assignee)

Comment 10

6 years ago
Created attachment 567713 [details] [diff] [review]
More mochitests
(Assignee)

Comment 11

6 years ago
Attachment 566165 [details] [diff] and attachment 567713 [details] [diff] [review] should be checked in as tests once this bug is opened.
Flags: in-testsuite?
(Assignee)

Updated

6 years ago
Attachment #566465 - Flags: approval1.9.2.23?
Attachment #566465 - Flags: approval-mozilla-beta?
Attachment #566465 - Flags: approval-mozilla-aurora?
(Assignee)

Comment 12

6 years ago
And backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/bfff1c1f8ed9 because it regressed bug 116882
(Assignee)

Updated

6 years ago
Attachment #566465 - Flags: approval1.9.2.23?
Attachment #566465 - Flags: approval-mozilla-beta?
Attachment #566465 - Flags: approval-mozilla-aurora?
(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.
Attachment #567738 - Attachment description: 0x81 0x82 testcase → 0x81 0x20 testcase
(Assignee)

Comment 15

6 years ago
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.
(Assignee)

Comment 17

6 years ago
Created attachment 567895 [details] [diff] [review]
Adjust behaviour and tests from bug 116882 to be compatible with IE
Attachment #567895 - Flags: review?(VYV03354)
Attachment #567895 - Flags: review?(VYV03354) → review+
(Assignee)

Comment 18

6 years ago
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
Attachment #566465 - Attachment is obsolete: true
Attachment #567895 - Attachment is obsolete: true
Attachment #567974 - Flags: review+
Attachment #567974 - Flags: checkin+
Attachment #567974 - Flags: approval1.9.2.23?
Attachment #567974 - Flags: approval-mozilla-beta?
Attachment #567974 - Flags: approval-mozilla-aurora?
(Assignee)

Comment 19

6 years ago
https://hg.mozilla.org/mozilla-central/rev/1b656851fd53
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
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
Attachment #567974 - Flags: approval1.9.2.24+
Attachment #567974 - Flags: approval1.9.2.23?
Attachment #567974 - Flags: approval-mozilla-beta?
Attachment #567974 - Flags: approval-mozilla-beta+
Attachment #567974 - Flags: approval-mozilla-aurora?
Attachment #567974 - Flags: approval-mozilla-aurora+
(Assignee)

Comment 21

6 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/10dca99e30c4
https://hg.mozilla.org/releases/mozilla-beta/rev/952cab8d5ff7
status-firefox8: --- → fixed
status-firefox9: --- → fixed
(Assignee)

Comment 22

6 years ago
https://hg.mozilla.org/releases/mozilla-1.9.2/rev/f0e3833cdcea
status1.9.2: --- → .24-fixed
qa+ for verification in Firefox 3.6.24, 8, and 9 using the attached PoC.
Whiteboard: [sg:high/moderate] → [sg:high/moderate][qa+]
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.
Keywords: verified1.9.2

Comment 25

6 years ago
Does this issue have a CVE assigned, or will it be a last minute one?
Alias: CVE-2011-3648
Depends on: 703868
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
Keywords: verified-beta
Status: RESOLVED → VERIFIED
Whiteboard: [sg:high/moderate][qa+] → [sg:high/moderate][qa!]
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 ?
Ok. Opera is the only browser which is vulnerable to this exploit now.

Comment 30

6 years ago
How is this exploit not present for 0x8F in euc-jp?
Group: core-security

Comment 31

5 years ago
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).
rforbes-bugspam-for-setting-that-bounty-flag-20130719
Flags: sec-bounty+
You need to log in before you can comment on or make changes to this bug.