Prevent UTF-7 tag injection in Gecko-generated directory listings (or other charsets)

RESOLVED WORKSFORME

Status

()

--
enhancement
RESOLVED WORKSFORME
11 years ago
3 years ago

People

(Reporter: masa141421356, Unassigned)

Tracking

({sec-low})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:low])

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: 

Now, nsEscapeHTML2() in /mozilla/source/xpcom/io/nsEscape.cpp does not escapes "+".
But, It causes to enable UTF-7 encoded script injection for directory list.
See also Bug 411433.

Reproducible: Always

Steps to Reproduce:
(Testcase of UTF-7 tag injection to directory list)

1.Creare directory to some named
+ADw-/title+AD4APA-meta http-equiv+AD0-content-type content+AD0-text/html+ADs-charset+AD0-utf-7/+AD4-/
aa+ACI-+AD4-+ADw-script+AD4-alert(location)+ADw-+AC8-script+AD4-

# +ADw-/
# title+AD4APA-meta http-equiv+AD0-content-type content+AD0-text/
# html+ADs-charset+AD0-utf-7/
# +AD4-/
# aa+ACI-+AD4-+ADw-script+AD4-alert(location)+ADw-+AC8-script+AD4-

2.Show directory list
3.Change encoding of directory list as UTF-7
Actual Results:  
Script in directory name is executed

Expected Results:  
Script should not executed

If "+" is escaped as "+" , it does not causes UTF-7 encoded tag injection.

Comment 1

11 years ago
How about not letting users force different charset interpretations of internally-generated pages such as directory lists?  That sounds more foolproof to me than just working around the problem for *one* of the charsets with the "Byte sequences that don't contain '<' can be decoded as character sequences that contain '<'" property.

Updated

11 years ago
Summary: Escape "+" as "&#43;" to disable UTF-7 tag injection → Escape "+" as "&#43;" to disable UTF-7 tag injection in Gecko-generated directory listings
(Reporter)

Comment 2

11 years ago
(In reply to comment #1)
> How about not letting users force different charset interpretations of
> internally-generated pages such as directory lists?

Looks fine.
But, it is needed to fix bugs arond charset inheritance in subframe (Bug 356280, Bug 412420, etc.)
(Reporter)

Comment 3

11 years ago
If UI of directory list is NOT imlemented by <SCRIPT> in directory list (like Fx2), security risk of tag injection seems to be same as risk of showing file that has same path of direcotory.

# If JavaScript is disabled, both of "script in injected tag at directory list"
# and "script in file" will blocked. but it does not blocks UI of directory list.

But at firefox-trunk, to enable UI of directory, JavaScript MUST be enabled for directory list. And it also enables to execute injected JavaScript.
(See also Bug 411480).

I think, If we want to implement UI of directory list by JavaScript written in its html, We have to block tag injection strictly.
I think Jesse is right.  Why not make this XHTML (instead of HTML) and then there is no charset injection issue of any kind?

Updated

11 years ago
Summary: Escape "+" as "&#43;" to disable UTF-7 tag injection in Gecko-generated directory listings → Prevent UTF-7 tag injection in Gecko-generated directory listings

Comment 5

10 years ago
UTF-7 was removed from browser menus in bug 441876, but I think there are other charsets with the same issue.

How does switching to XHTML help?  Does that disable all the charset menu items?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [sg:low]
Summary: Prevent UTF-7 tag injection in Gecko-generated directory listings → Prevent UTF-7 tag injection in Gecko-generated directory listings (or other charsets)
Yes.  When doing XML, we only use the HTTP header and the XML declaration for charset information.  We do not use any other sources, including user overrides.  You can select whatever you want in the charset menu, and we'll reload the page, but whatever you selected in the menu will be ignored.

Comment 7

10 years ago
nsIndexedToHTML.cpp sets the charset of the entire page based on something from the server, so converting its output to XHTML might not be straightforward.  That was added in bug 162377.
Depends on: 414064
(Reporter)

Comment 9

8 years ago
I think, we can mark this bug as WONTFIX (or INVALID ) because UTF-7 support is already removed.
Group: network-core-security
Group: network-core-security

Updated

3 years ago
Group: core-security → network-core-security
comment 9
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
Group: network-core-security
Resolution: INVALID → WORKSFORME
You need to log in before you can comment on or make changes to this bug.