HTML special characters are not commented in FTP directory listings

VERIFIED FIXED

Status

()

Core
Networking: FTP
--
major
VERIFIED FIXED
17 years ago
15 years ago

People

(Reporter: 3APA3A, Assigned: bbaetz)

Tracking

({testcase})

Trunk
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.3) Gecko/20010801
BuildID:    2001080110

If filename in FTP directory contains HTML tags this tags will be part of HTML
page with file listing. Javascript in filenames will be executed. There is
security impact (for example user who can only upload files but cann't modify
uploaded files can modify directory listings) but it's not high though.

Reproducible: Always
Steps to Reproduce:
1. on ftp server create (or upload) file with HTML tag in the name (example:
 touch "/ftp/incoming/123/<img src=\"javascript:alert('Hello World')\">" or
upload file with name like this via ftp.
2. open FTP URL (example: ftp://server/incoming/123)
. 

Actual Results:  You will see "Hello world" alert.

Expected Results:  to see <img src=\"javascript:alert('Hello World')\"> as a
file name
(Assignee)

Comment 1

17 years ago
I can't test this at the moment, but confirming based on 
http://lxr.mozilla.org/seamonkey/source/netwerk/streamconv/converters/nsIndexedT
oHTML.cpp#164.

We need to unescape this, and then entitise it (> -> &gt;, etc). Do we have a 
generic function to do that which is available from necko?

-> critical
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: want for 0.9.4
(Assignee)

Updated

17 years ago
Group: security?
(Assignee)

Updated

17 years ago
Group: security?
(Assignee)

Comment 2

17 years ago
err. Note to self: do not comment on bugs after spending 9 hours on a flight. 
Lets try this again.

Theres not that much of a security impact - you can't do anything you couldn't 
do as part of a webpage, right. Its unexpected, and its wrong (and a url with a 
< in it probably stuffs up later entries), but I can't think of an exploit.
Severity: critical → major
Whiteboard: want for 0.9.4

Comment 3

17 years ago
Can you use it to add inline graphics to an FTP display? That would solve some
aspects of bug 90695. :)

Comment 4

17 years ago
I can't seam to make this work.  I do see the inline script  being to be
evaulated, but nsJSThunk::EvaluateScript() prevents this because the underlying
netlib channel  (nsStreamIOChannel) does not have an interface requestor.

I do not think that this is critical.   Mitch, do you concur?  
(Assignee)

Comment 5

17 years ago
benc: I've done the icons in my dirviewer rewrite.
I can't reproduce this either, but it's got me worried. If there were a way to
insert a script into an FTP directory listing, it would run with the system
principal (=the system is compromised). IMG SRC=javascript:... doesn't seem to
do anything when I tried it, and I can't seem to insert <SCRIPT> tags this way
either, because they don't work without the corresponding </SCRIPT>, and I can't
figure out how to escape the slash in the filename. There may be a way though.

HTML tags in filenames are definitely being parsed. I tried naming a file
"para<p>para" and listing the directory via ftp, and got the new paragraph in
the middle of the name. 

So there's a possiblility that this is critical. Would it be difficult to escape
HTML tags in filenames? Let's do this if we can; otherwise I think we're asking
for trouble.

Comment 7

17 years ago
Run with the system principal?  How so?  

I do not see how this is different than a webpage.  Please advise.
(Reporter)

Comment 8

17 years ago
OK, it looks like <IMG SRC="javascript:"> doesn't work each time (I was able to 
reproduce it for few times though). There is another way to execute javascript 
or anything you want through this bug, check ftp://ftp.sandy.ru/incoming/6
I've created file with name <META HTTP-EQUIV="Refresh" CONTENT="1; 
URL=malware.htm"> in the ftp://ftp.sandy.ru/incoming/6 and put mailware.htm 
into /incoming (for reasons I don't understand this url requests 
ftp://ftp.sandy.ru/incoming/malware.htm instead of 
ftp://ftp.sandy.ru/incoming/6/malware.htm, but who cares?).

BTW: is it right <META> tag is accepted in document body outside header? I 
think it is not correct, but I'm not sure about HTML standards.
BTW[2]: it looks there are 2 more bugs in FTP
 1. It's impossible to enter empty directory
 2. Directory content is cashed. If you remove or add some files to directory 
there is no way to refresh directory content without clearing the cash. 
Have I open new bids for these bugs?
(Assignee)

Comment 9

17 years ago
Um. How does this run with the system prinicpal? This is a stream converter - if
stream converters have any elevated privs then we run into bug 51442 again,
don't we?
(Assignee)

Comment 10

17 years ago
I've fixed this in my rewrite. The fix is to add a call to nsEscapeHTML before
outputting the description.

dougt: I don't have net access at home yet, and I have my other ftp patch in the
way - can you do this?
I don't know if this runs with the system principal or not, but regardless, you
shouldn't be able to sneak in HTML like this - it'll cause trouble one way or
another. Let's escape < and > as proposed. Is there a patch already posted
somewhere else?
(Assignee)

Comment 12

17 years ago
No patch per se - I don't have web access at home til the middle of next week.

The following untested-but-something-similar-works-in-my-heavily-hacked-tree
pseudo-diff via lxr of nsIndexedToHTML.cpp should work though:

164     nsUnescape(NS_CONST_CAST(char*, filename.get()));
+       char* htmlEscaped = nsEscapeHtml(filename.get());
-165     pushBuffer.AppendWithConversion(filename);
+       pushBuffer.AppendWithConversion(htmlEscaped);
+       nsMemory::Free(htmlEscaped);
166     pushBuffer.AppendWithConversion("</a>");

This function (used by the mime code), escapes <, >, &, and ".

+patch, review. I guess.
Keywords: patch, review

Comment 13

17 years ago
reassigning to bbaetz@cs.mcgill.ca.
Assignee: dougt → bbaetz

Comment 14

17 years ago
+makingtest
(Assignee)

Comment 15

17 years ago
I fixed this last week when my dirviewer patch landed. Missed marking it fixed
because this wasn't listed as a dependancy.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 16

16 years ago
VERIFIED: Mozilla 1.0, RC1, Win98
Status: RESOLVED → VERIFIED
Keywords: testcase

Comment 17

15 years ago
had minor problems creating the file, I used:

touch '<img src=\"javascript:alert('Hello\ World')\">'
You need to log in before you can comment on or make changes to this bug.