User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) 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:184.108.40.206) 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.
Linux box might be exploitable by: resource:///something.com;\\..\\..\\..\\ (as I haven't tried it in a Linux box yet)
Steps to Reproduce:
1. In windows, Open the following URL by using Mozilla Firefox:
2. You can see the root directory
You can see the root directory
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.
I'm also not sure if we should be able to use "resource" protocol without doing
files in the Mozilla Firefox directory can be loaded such as:
any comment? any sugegstion? any feedback?
It's on my list. The symptom from comment 1 is intentional, not a bug.
I think we can refer to these links:
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.
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.
Actually, I'm going to delegate.
I hope we can get a result soon.
I'd argue that this should block 2.0, sg:high bug.
Is it eligible for the security bug bounty?
I added the bug to the bounty request queue. We usually don't decide until we understand the fix.
(In reply to comment #3)
> It's on my list. The symptom from comment 1 is intentional, not a bug.
Reproducible on Windows. I can't reproduce this on Linux, likely because backslashes aren't interpreted as directory separators.
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)
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.
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.
It's a twisty maze of twistiness, but here's where it starts:
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.
Sorry, I meant param not ref portions above.
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
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.
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
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.
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.
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.
Created attachment 509230 [details] [diff] [review]
Created attachment 509231 [details] [diff] [review]
This applies to 1.9.2 and 1.9.1.
Note: please do not check in the tests for this patch until after it has been included in a release.
Comment on attachment 509231 [details] [diff] [review]
a=LegNeato for 220.127.116.11 and 18.104.22.168
Holding off on landing tests.
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.
On trunk, I don't think it's possible to repro. On branches on Windows, "resource:///;\..\..\" will do it. Mac/Linux are unaffected.
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?
(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 firstname.lastname@example.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.
Created attachment 511514 [details] [diff] [review]
tests for trunk
Posting trunk tests for the record. (This needs to be landed after branch release.)
Created attachment 511515 [details] [diff] [review]
(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
Thanks for the comment. I'm still waiting for the result of bug bounty on this bug.
(In reply to comment #4)
> I think we can refer to these links:
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.
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.
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.
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.
Did the tests ever land here?
I don't believe so. A volunteer would be appreciated, since I have no treewatching time at present. I can ask around!
I'll grab them next time I push.