Bug 801681 (CVE-2012-4207)

"~" eats a char near chunk delimiter in HZ-GB-2312 encoding

RESOLVED FIXED in Firefox 17



5 years ago
3 years ago


(Reporter: Masato Kinugawa, Assigned: smontagu)


({regression, sec-high, testcase})

regression, sec-high, testcase
Bug Flags:
sec-bounty +
in-testsuite +

Firefox Tracking Flags

(firefox16 affected, firefox17 fixed, firefox18 fixed, firefox19 fixed, firefox-esr1017+ fixed, firefox-esr17 fixed)


(Whiteboard: [adv-track-main17+][adv-track-esr17+] XSS against sites using this charset)


(3 attachments, 2 obsolete attachments)



5 years ago
User Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20100101 Firefox/16.0
Build ID: 20121010144125

Steps to reproduce:

In HZ-GB-2312 encoding, "~" eats a char near chunk delimiter. This behavior is Firefox only. 

This leads to XSS attack:

Also, this has potential risk of Bug 690225.

Expected results:

"~" should not eat character.
Component: Untriaged → Internationalization
Product: Firefox → Core
Matt: please capture this testcase and add it as an attachment.
Ever confirmed: true
Flags: needinfo?(mwobensmith)
Keywords: sec-high, testcase
Whiteboard: XSS against sites using this charset
Created attachment 672400 [details]
Captured from http://vulnerabledoma.in/fx_hz?q=~%20123
Flags: needinfo?(mwobensmith)
Created attachment 672572 [details]
captured testcase

More faithful capture... the previous attachment suffered from browser translation of >< to &gt;&lt; which broke the testcase -- onmouseover triggered because it was legitimately in the source regardless of charset.

If you load this testcase as the hz-gb-2312 charset you see one <input> with an alert triggered on mouseover. If you then go to the View menu and change the Character Encoding to UTF-8 you will see two inputs, with "~ 123" in one and the onmouseover injection in the other.
Attachment #672400 - Attachment is obsolete: true
Comment on attachment 672572 [details]
captured testcase

This doesn't work either. The only obvious difference I see is that vulnerabledoma.in is using Transfer-Encoding: chunked and there's no way to do that for an attached testcase that I know of.
Attachment #672572 - Attachment is obsolete: true

Comment 5

5 years ago
Created attachment 672713 [details]
Alternative testcase

The bug is there in the decoder even without the chunking - this testcase finds another way to exhibit it.
Assignee: nobody → smontagu


5 years ago
Blocks: 715319
Keywords: regression

Comment 6

5 years ago
Created attachment 672714 [details] [diff] [review]

When unconsuming the character we need to decrement the loop index as well as the source pointer.

The patch fixes another error, not related to this bug: we should only increment iDestlen++ when actually outputting a character. I need to work out a testcase for that as well.
Attachment #672714 - Flags: review?(VYV03354)
Attachment #672714 - Flags: review?(VYV03354) → review+


5 years ago
status-firefox-esr10: --- → affected
status-firefox16: --- → affected
status-firefox17: --- → affected
status-firefox18: --- → affected
status-firefox19: --- → affected

Comment 7

5 years ago
OS: Windows Vista → All
Hardware: x86 → All
Version: 16 Branch → Trunk

Comment 8

5 years ago
Created attachment 672922 [details]
Testcase 2

This is a testcase for the second issue mentioned in comment 6. Without the patch it asserts:
###!!! ASSERTION: The Unicode decoder consumed the wrong number of bytes.: 'totalByteCount == (int32_t)aCount', file parser/html/nsHtml5StreamParser.cpp, line 869
###!!! ASSERTION: Wrong number of stream bytes written/sniffed.: 'writeCount == aLength', file parser/html/nsHtml5StreamParser.cpp, line 1077
Last Resolved: 5 years ago
status-firefox19: affected → fixed
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla19

Comment 10

5 years ago
Comment on attachment 672714 [details] [diff] [review]

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 715319
User impact if declined: Possibility of XSS attack in pages encoded in HZ-GB-2312
Testing completed (on m-c, etc.): On m-c since 2012-10-18
Risk to taking this patch (and alternatives if risky): minimal
String or UUID changes made by this patch: None
Attachment #672714 - Flags: approval-mozilla-esr10?
Attachment #672714 - Flags: approval-mozilla-beta?
Attachment #672714 - Flags: approval-mozilla-aurora?
Attachment #672714 - Flags: approval-mozilla-esr10?
Attachment #672714 - Flags: approval-mozilla-esr10+
Attachment #672714 - Flags: approval-mozilla-beta?
Attachment #672714 - Flags: approval-mozilla-beta+
Attachment #672714 - Flags: approval-mozilla-aurora?
Attachment #672714 - Flags: approval-mozilla-aurora+
tracking-firefox-esr10: --- → 17+
status-firefox-esr10: affected → fixed
status-firefox17: affected → fixed
status-firefox18: affected → fixed
status-firefox-esr17: --- → fixed
Whiteboard: XSS against sites using this charset → [adv-track-main17+][adv-track-esr17+] XSS against sites using this charset
Alias: CVE-2012-4207
Keywords: verifyme


5 years ago
Flags: sec-bounty?
Flags: sec-bounty? → sec-bounty+
Group: core-security

Comment 13

5 years ago
Tests checked in https://hg.mozilla.org/integration/mozilla-inbound/rev/f27d5d9ebef2
Flags: in-testsuite? → in-testsuite+
mass remove verifyme requests greater than 4 months old
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.