Last Comment Bug 624764 - (CVE-2011-0071) Directory Traversal in resource protocol
(CVE-2011-0071)
: Directory Traversal in resource protocol
Status: RESOLVED FIXED
[sg:moderate?][hardblocker]
:
Product: Core
Classification: Components
Component: Networking (show other bugs)
: unspecified
: x86 Windows XP
: -- major with 1 vote (vote)
: ---
Assigned To: dwitte@gmail.com
:
Mentors:
resource:///www.secproject.com;\..\.....
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-01-11 09:58 PST by Soroush Dalili
Modified: 2014-07-22 13:05 PDT (History)
10 users (show)
rforbes: sec‑bounty+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
betaN+
.17+
.17-fixed
.19+
.19-fixed


Attachments
trunk patch (2.25 KB, patch)
2011-02-02 14:16 PST, dwitte@gmail.com
benjamin: review+
Details | Diff | Splinter Review
branch patch (2.26 KB, patch)
2011-02-02 14:16 PST, dwitte@gmail.com
benjamin: review+
christian: approval1.9.2.17+
christian: approval1.9.1.19+
Details | Diff | Splinter Review
tests for trunk (1.67 KB, patch)
2011-02-10 14:36 PST, dwitte@gmail.com
no flags Details | Diff | Splinter Review
branch tests (1.68 KB, patch)
2011-02-10 14:36 PST, dwitte@gmail.com
no flags Details | Diff | Splinter Review

Description Soroush Dalili 2011-01-11 09:58:53 PST
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 2011-01-11 10:06:02 PST
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 2011-01-14 06:55:00 PST
any comment? any sugegstion?  any feedback?
Comment 3 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2011-01-14 10:42:27 PST
It's on my list. The symptom from comment 1 is intentional, not a bug.
Comment 4 Soroush Dalili 2011-01-14 15:45:37 PST
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 AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2011-01-16 08:35:11 PST
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 AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2011-01-18 13:09:00 PST
Actually, I'm going to delegate.
Comment 7 Soroush Dalili 2011-01-18 13:30:54 PST
I hope we can get a result soon.
Comment 9 Johnny Stenback (:jst, jst@mozilla.com) 2011-01-20 13:22:04 PST
I'd argue that this should block 2.0, sg:high bug.
Comment 10 Soroush Dalili 2011-01-20 14:37:53 PST
Is it eligible for the security bug bounty?
Comment 11 Daniel Veditz [:dveditz] 2011-01-21 10:55:12 PST
I added the bug to the bounty request queue. We usually don't decide until we understand the fix.
Comment 12 dwitte@gmail.com 2011-01-24 16:59:31 PST
(In reply to comment #3)
> It's on my list. The symptom from comment 1 is intentional, not a bug.

Why?
Comment 13 dwitte@gmail.com 2011-01-26 18:05:47 PST
Reproducible on Windows. I can't reproduce this on Linux, likely because backslashes aren't interpreted as directory separators.
Comment 14 Soroush Dalili 2011-01-27 00:42:30 PST
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 dwitte@gmail.com 2011-01-27 13:39:58 PST
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 2011-01-27 13:59:04 PST
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 dwitte@gmail.com 2011-01-27 14:35:04 PST
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 dwitte@gmail.com 2011-01-27 14:38:44 PST
Sorry, I meant param not ref portions above.
Comment 19 dwitte@gmail.com 2011-01-27 15:16:39 PST
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 2011-01-27 15:55:01 PST
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 dwitte@gmail.com 2011-02-01 17:43:13 PST
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 AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2011-02-01 19:42:49 PST
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 dwitte@gmail.com 2011-02-02 00:19:37 PST
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 dwitte@gmail.com 2011-02-02 14:16:29 PST
Created attachment 509230 [details] [diff] [review]
trunk patch
Comment 25 dwitte@gmail.com 2011-02-02 14:16:57 PST
Created attachment 509231 [details] [diff] [review]
branch patch

This applies to 1.9.2 and 1.9.1.
Comment 26 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2011-02-02 14:23:07 PST
Note: please do not check in the tests for this patch until after it has been included in a release.
Comment 27 christian 2011-02-02 14:38:15 PST
Comment on attachment 509231 [details] [diff] [review]
branch patch

a=LegNeato for 1.9.2.15 and 1.9.1.18
Comment 29 Al Billings [:abillings] 2011-02-04 14:59:53 PST
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 dwitte@gmail.com 2011-02-04 16:00:47 PST
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 2011-02-05 15:01:41 PST
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] (use needinfo?) 2011-02-05 15:26:25 PST
(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 security@mozilla.org. 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 dwitte@gmail.com 2011-02-10 14:36:04 PST
Created attachment 511514 [details] [diff] [review]
tests for trunk

Posting trunk tests for the record. (This needs to be landed after branch release.)
Comment 34 dwitte@gmail.com 2011-02-10 14:36:21 PST
Created attachment 511515 [details] [diff] [review]
branch tests

Branch tests.
Comment 35 Soroush Dalili 2011-02-14 13:57:06 PST
(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] 2011-02-18 11:50:33 PST
(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 2011-02-19 16:08:40 PST
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] 2011-02-22 16:08:24 PST
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] 2011-03-04 10:14:54 PST
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 [:khuey] (khuey@mozilla.com) 2011-06-07 21:45:05 PDT
Did the tests ever land here?
Comment 41 dwitte@gmail.com 2011-06-08 00:20:25 PDT
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 [:khuey] (khuey@mozilla.com) 2011-06-08 05:40:27 PDT
I'll grab them next time I push.
Comment 43 Raymond Forbes[:rforbes] 2013-07-19 18:06:49 PDT
rforbes-bugspam-for-setting-that-bounty-flag-20130719

Note You need to log in before you can comment on or make changes to this bug.