624764 - (CVE-2011-0071) Directory Traversal in resource protocol

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Soroush Dalili]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 ( .NET CLR 3.5.30729; .NET4.0E)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 ( .NET CLR 3.5.30729; .NET4.0E)

By using a semi-colon ";" character after the resource protocol, we can bypass the protections and use "\..\" in order to do directory traversal or use the colon ":" character.
It can be used for file/directory enumeration or including important javascript files in a script tag. For example for a windows box we can use:
<script src="resource:///;\..\..\..\directory\secret.js"></script>
Or
<script src="resource:///;\..\..\..\directory\secret.js::$data"></script>
Or
<script src="resource:///something.com;\..\..\..\directory::$index_allocation\secret.js"></script>

---
Linux box might be exploitable by: resource:///something.com;\\..\\..\\..\\ (as I haven't tried it in a Linux box yet)

Reproducible: Always

Steps to Reproduce:
1. In windows, Open the following URL by using Mozilla Firefox:
resource:///;\..\..\..\
2. You can see the root directory
Actual Results:  
You can see the root directory

Expected Results:  
I should be limited and get "access denied" for example

I just find this bug in 15 minutes, and I am reporting this immediately to you after finding it. Therefore, excuse me if I have any mistake in writing the report.

Comment 1

[Soroush Dalili]

I'm also not sure if we should be able to use "resource" protocol without doing
any directory traversal in a script tag as well! In this case, the javascript
files in the Mozilla Firefox directory can be loaded such as:
resource:///components/FeedConverter.js
For example:
<script src="resource:///components/FeedConverter.js"></script>

Comment 2

[Soroush Dalili]

any comment? any sugegstion?  any feedback?

Comment 3

[Benjamin Smedberg]

It's on my list. The symptom from comment 1 is intentional, not a bug.

Comment 4

[Soroush Dalili]

I think we can refer to these links:
https://bugzilla.mozilla.org/show_bug.cgi?id=367428
http://www.securityfocus.com/bid/24191/discuss
and
http://www.mozilla.org/security/announce/2008/mfsa2008-05.html

I think it is a major issue. However, if you think it's not a security bug (or it is a low risk), I will release it via by blog with some PoC. Therefore, this bug can come out to public (I have a smililar one in IE8 and I like to mix them together in a Poc ;) ). 
I'm waiting for your response.

Please let me know.

Comment 5

[Benjamin Smedberg]

It is a security bug, currently rated [sg:high] (leak of local user files to websites). Please do not release details of this until we have had a change to fix this bug and push it out to users in a Firefox release. This bug is eligible for the security bug bounty, I think, if that's what you're asking. I don't know exactly how that process works, cc'ing some people who do.

Comment 6

[Benjamin Smedberg]

Actually, I'm going to delegate.

Comment 7

[Soroush Dalili]

I hope we can get a result soon.

Comment 9

[Johnny Stenback (:jst)]

I'd argue that this should block 2.0, sg:high bug.

Comment 10

[Soroush Dalili]

Is it eligible for the security bug bounty?

Comment 11

[Daniel Veditz [:dveditz]]

I added the bug to the bounty request queue. We usually don't decide until we understand the fix.

Comment 12

[[e-mail]]

(In reply to comment #3)
> It's on my list. The symptom from comment 1 is intentional, not a bug.

Why?

Comment 13

[[e-mail]]

Reproducible on Windows. I can't reproduce this on Linux, likely because backslashes aren't interpreted as directory separators.

Comment 14

[Soroush Dalili]

have you tried this one in linux as well: resource:///something.com;\\..\\..\\..\\
Is it important to work on the exploitation technique now? (if it is so, I will try to do it)

Comment 15

[[e-mail]]

Yes. I can't get any of this to reproduce under Linux.

Also, I think this bug is only reproducible on branch: on trunk we have omnijar, so the outer URI is a jar one and it inherently disallows poking outside of the jar.

Comment 16

[Soroush Dalili]

Could you please give me a direct link to the source code that you are looking at. 
Yes, you cannot do the same when you are calling a jar file by "jar:"(chrome). However, I would be thankful if you give me a link to the protection code of omnijar if you know about it as well.

Comment 17

[[e-mail]]

It's a twisty maze of twistiness, but here's where it starts:
http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/res/nsResProtocolHandler.cpp#466

The input to that method is a resource:// URI. On branch, the result of that method is a file:// URI, which is resolved via http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsStandardURL.cpp#1720. On trunk, it's a jar:file:// URI. From there, we presumably go through several steps to get an nsILocalFile (on branch) and thus an output stream that we can serve up. (This may involve http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsURLHelperWin.cpp#86, which calls http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsURLHelper.cpp#181.) What I can't figure out yet is how this vulnerability comes about; in net_ParseFileURL, we deal with ';' ref portions just fine, and don't include them in the filepath which is used to construct the nsILocalFile.

There's an easy fix, of course, if we make nsResProtocolHandler::ResolveURI disallow this stuff. But it worries me that the ';' could sneak through (and be interpreted as part of the filepath!) given all the other parsing we do, and that may warrant a more generic fix. I'm going to have to step through this stuff when I get onto my Windows machine and see what codepaths we're hitting.

Comment 18

[[e-mail]]

Sorry, I meant param not ref portions above.

Comment 19

[[e-mail]]

From http://www.ietf.org/rfc/rfc2396.txt §3.3:

   The path may consist of a sequence of path segments separated by a
   single slash "/" character.  Within a path segment, the characters
   "/", ";", "=", and "?" are reserved.  Each path segment may include a
   sequence of parameters, indicated by the semicolon ";" character.
   The parameters are not significant to the parsing of relative
   references.

So apparently ';' is legal within *individual* path segments; and it's explicitly named in http://mxr.mozilla.org/mozilla-central/source/netwerk/base/public/nsIURL.idl#48 as a suffix which can appear after the directory/filename portion. I'm not sure of its intended meaning in either case, or of any real-world usage (other than as a delimiter inside a '?' string).

Regardless, I can't possibly see how it would be intentional that it be interpreted as part of a path or path segment when dealing with local files.

Comment 20

[Soroush Dalili]

Thanks for the information.
Semi-colon character is used on some webservers that support CGIs/JSP/Servlet as a delimiter; and that's why I tried it.
According to: http://www.w3.org/TR/html401/appendix/notes.html#h-B.2.2
"We recommend that HTTP server implementors, and in particular, CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner."
We can also have file/folder with semi-colon in its name.
Semi-colon has caused logical issues for other applications/systems before. For example: http://soroush.secproject.com/downloadable/iis-semicolon-report.pdf

Comment 21

[[e-mail]]

OK. When parsing a path, we search forward for '?' and '#'; the first such occurrence is tagged as the query / ref portion respectively. We search for ';' backwards until we hit the first '/', which occurs *after* normalization of the paths' '\\' components to '/'. So we're explicit about treating ';' as a param portion only in the filename segment of the URL. Coupled with the fact that ';' is legal in pathnames, this all makes sense. (I think.)

The usual sequence of events for dealing with a "resource:///../"-like URL would be for the "/../" to be coalesced out before we even get to nsResProtocolHandler::ResolveURI. This would work fine if we normalized '\\' to '/' at that point, since then we'd treat ';\\..\\..\\' as ';/../../' which would coalesce to nothing. The alternative, I think, is to manually normalize and coalesce the path in nsResProtocolHandler::ResolveURI.

Comment 22

[Benjamin Smedberg]

I think it makes more sense to say that a resource: URI with a semicolon anywhere in it is simply invalid. We don't have to support arbitrary complexity for our own URI schemes.

Comment 23

[[e-mail]]

I was thinking of fixing this more generically by forcing unescaping and path normalization ('\' --> '/') before we resolve the resource:// URI. But doing so would require performing OS-dependent normalization which is currently only done in net_GetFileFromURLSpec, which would be a pain.

So I think you're right, we can fix this simply by unescaping and checking for '\' in the full path rather than the file path. There's no need to test for ';' at that point since it's harmless. I'm running that patch through try.

Comment 24

[[e-mail]]

Attachment: trunk patch

Comment 25

[[e-mail]]

Attachment: branch patch

This applies to 1.9.2 and 1.9.1.

Comment 26

[Benjamin Smedberg]

Note: please do not check in the tests for this patch until after it has been included in a release.

Comment 27

[LegNeato]

Comment on attachment 509231 [details] [diff] [review]
branch patch

a=LegNeato for 1.9.2.15 and 1.9.1.18

Comment 28

[[e-mail]]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/cf6f4bb351f7
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/9eb3aa442404
http://hg.mozilla.org/mozilla-central/rev/6f2a03f7876d

Holding off on landing tests.

Comment 29

[Al Billings [:abillings - ex-MoCo]]

What is the exact STR here for branch and for trunk?

On trunk, as noted, I cannot get outside of omni.jar with the examples above.

Comment 30

[[e-mail]]

On trunk, I don't think it's possible to repro. On branches on Windows, "resource:///;\..\..\" will do it. Mac/Linux are unaffected.

Comment 31

[Soroush Dalili]

Glad that this bug has been solved. Now guys, I'm not sure about the bounty process, how can I realise if this one can get it or not? 

And for my information, do you suggest the security researchers to still report the security bugs that cannot be eligble for the bug bounty as well? if yes, why do you?

Comment 32

[Reed Loden [:reed]]

(In reply to comment #31)
> Glad that this bug has been solved. Now guys, I'm not sure about the bounty
> process, how can I realise if this one can get it or not? 

This bug was nominated for a bug bounty on Jan. 20th, but you'll need to wait until the bounty committee meets (around once a month) to find out if the nomination is accepted. If it is accepted, you'll be contacted via e-mail.

> And for my information, do you suggest the security researchers to still report
> the security bugs that cannot be eligble for the bug bounty as well? if yes,
> why do you?

Sure, even if something doesn't explicitly qualify for a bug bounty (as per the policy), the committee has been known to grant bounties for clever bug findings and other special circumstances. In some cases, the researcher might not be aware that his/her lower-severity bug could be modified slightly or used with some other bug to expand privileges, which would make the issue more critical than originally considered by the researcher. By submitting bugs, you're helping to improve the security of Firefox and other Mozilla projects and doing your part to protect millions of users. Plus, almost all security issues end up in a security advisory, which would include the submitter's name, in case credit means a lot to you (i.e., more security cred for finding a Firefox vulnerability or something). There are many reasons why you should still submit your findings, but in the end, it is your choice, though we hope you will notify us rather than keep the issues to yourself.

If you have any other questions about the bug bounty program, please contact [e-mail]. We generally try to keep the bounty process outside of the bugs themselves so as not to interfere with development of security fixes, but we're more than happy to answer any and all questions/concerns/comments you have about how this process works.

Thanks!

Comment 33

[[e-mail]]

Attachment: tests for trunk

Posting trunk tests for the record. (This needs to be landed after branch release.)

Comment 34

[[e-mail]]

Attachment: branch tests

Branch tests.

Comment 35

[Soroush Dalili]

(In reply to comment #33)
> Created attachment 511514 [details] [diff] [review]
> tests for trunk
> Posting trunk tests for the record. (This needs to be landed after branch
> release.)

Thanks for the comment. I'm still waiting for the result of bug bounty on this bug.

Regards
Sorous

Comment 36

[Daniel Veditz [:dveditz]]

(In reply to comment #4)
> I think we can refer to these links:
> http://www.mozilla.org/security/announce/2008/mfsa2008-05.html

The difference between this one and MFSA 2008-05 is on that one the traversal started in the profile directory which opened up juicy JS-formatted files that could be read (e.g. user's prefs, sessionrestore data). The resource: scheme starts in the install directory and profile data should be obscured by the directory name salting.

non-JS files will just give you syntax errors if you try to load them, but no stolen data. You could probably fingerprint someone by looking in common locations for what kinds of things they have installed, but that's a lower severity privacy attack.

Lowering the severity to moderate and recommending a reduced bounty, but it's possible I've completely missed some common trove of data you can capture using this technique. Here's your chance to appeal to restore the full sg:high rating.

Comment 37

[Soroush Dalili]

I'm trying to see if there is a way to find the profile name and include the "sessionstore.js" by using this attack. I'll write my result here which was successful or failed for the final judge.
Thanks.

Comment 38

[Daniel Veditz [:dveditz]]

By default we add random characters to the profile name to defeat this type of attack. If you can find a way to determine the salted profile name that would be an interesting bug in its own right.

There may be standard OS files that can be read in JS format. If there are any those are more likely to be reachable in predictable locations.

Comment 39

[Daniel Veditz [:dveditz]]

The "3.6.15" we're releasing today does not fix this bug, the release containing this bug fix has been renamed to "3.6.16" and the bugzilla flags will be updated to reflect that soon. Today's release is a re-release of 3.6.14 plus a fix for a bug that prevented many Java applets from starting up.

Comment 40

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Did the tests ever land here?

Comment 41

[[e-mail]]

I don't believe so. A volunteer would be appreciated, since I have no treewatching time at present. I can ask around!

Comment 42

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I'll grab them next time I push.

Comment 43

[Raymond Forbes[:rforbes]]

rforbes-bugspam-for-setting-that-bounty-flag-20130719