Community
Participate
Working Groups
This is probably an upstream issue, but I will raise it here as it is reproducible in the IDE. If a ( or \ character is appended to a URL to the help system, then the source of the JSP page is rendered instead of the page itself. For the IDE, this is not a big issue (the code is opensource anyway), but if the issue is in the HttpServer or Jetty itself, then this is a significant security issue. We have check jetty 6.1.23, 6.1.26 and jetty-7 out of the box, and none of them are vulnerable to this issue. So it is something about the configuration of Jetty in eclipse IDE, the HttpService, or the JSP library used. So I've opened this issue here in the expectation that we can work upstream to identify which component/configuration is the cause. I will continue to evaluation jetty's handling of such requests and work out what mechanism is catching these URLs and thus work out what could be potentially be disabled in the IDE or RT.
I can't repeat this behaviour using local help or help.eclipse.org on Chrome, Firefox, or wget on Ubuntu, Windows XP. http://help.eclipse.org/helios/index.jsp\ is changed to http://help.eclipse.org/helios/index.jsp/ (by Chrome, I presume) and results in a 404. http://help.eclipse.org/helios/index.jsp( results in a blank page On Firefox both result in a blank page. wget also returns blank pages. Am I getting the URL wrong?
Oh yes... version info... Eclipse for RCP and RAP Developers Version: Helios Release Build id: 20100617-1415 I'm not sure what version of the help system we have installed on help.eclipse.org. I does report jetty:/// in the 404 message...
I'm having no luck reproducing with IDE Help in 3.7 HEAD using a wider set of browsers. I've also tried another set of JSPs I use for testing without luck. Greg, is there a link to the original problem report or have you had any luck creating a test case?
I'm running Helios Version: 3.6.1.r361_v20100714-0800-7z8XFUSFLFlmgLc5z-Bvrt8-HVkH on Linux Brick 2.6.35-22-generic #35-Ubuntu SMP Sat Oct 16 20:45:36 UTC 2010 x86_64 GNU/Linux Note that it is not the help on the help.eclipse.org site, but the help running within the IDE itself. To reproduce: 1) Run the IDE 2) select Help->Help Contents 3) hover over a link and observe the URL in the status bar, it will be something like http://127.0.0.1:32172/help/... 4) In a browser (I'm using FF-3.6.11) type in the URL http://127.0.0.1:32172/help/advanced/tocView.jsp - you should see the TOC 5) Now add a ( or \ to the URL http://127.0.0.1:32172/help/advanced/tocView.jsp( and you will see the source code.
(In reply to comment #4) > 5) Now add a ( or \ to the URL > http://127.0.0.1:32172/help/advanced/tocView.jsp( and you will see the source > code. I get the described behavior with this URL on both Chrome and Firefox. So it seems to be URL-dependent.
I just noticed that if I trigger a 404, then the IDE reports an error page that says: HTTP ERROR 404 Problem accessing /help/advanced/tocView.jsp!fasfda. Reason: ProxyServlet: /help/advanced/tocView.jsp!fasfda Powered by Jetty:// So there is a ProxyServlet involved. I don't know if this is the Jetty ProxyServlet or an eclipse one?
Ah! I just got the error on the actual eclipse site. So it might not be jetty, but it could be whatever the site is running. Try http://help.eclipse.org/helios/advanced/tocView.jsp(
Sorry for the rapid fire comments. The URL http://help.eclipse.org/helios/advanced/tocView.jsp%28 reveals the source for me on all my available browsers. The server running there is apache, but I cannot tell from the headers what JSP engine is being used. The error pages suggest that it is jetty that is running behind apache on that machine - so it would be good to find out the version etc. I will setup mod_jk environment here.
Actually, I'll need to know how apache and jetty are linked: mod_jk, mod_proxy_ajp or mod_proxy_http.
Webmaster, please see Comment 9.
> Actually, I'll need to know how apache and jetty are linked: mod_jk, > mod_proxy_ajp or mod_proxy_http. We use apaches mod_proxy to re-write & proxy the requests to the headless eclipse processes. #eclipse 3.3 (europa) RewriteRule ^/help33/$ http://help.eclipse.org/help33/index.jsp [R,L] ProxyPass /help33 http://localhost:port/help ProxyPassReverse /help33 http://localhost:port/help -M.
I agree that it is not a good practice to allow the source of the jsp files to be read from a web server but in the case of Eclipse the source of the .jsp files is readily available so this bug is not critical. It still makes sense to fix the bug if it is not too difficult. It looks as though the jsp file is being read as a resource and separating the resources and jsp files into separate directories may be one way to accomplish this.
I can also see a problem deeper down in equinox where we do a call to bundle.findEntries and we're finding a match even though the filename we're querying for ends in "(" or "\". I'll dig deeper but we should not be finding a match in this case.
(In reply to comment #12) > I agree that it is not a good practice to allow the source of the jsp files to > be read from a web server but in the case of Eclipse the source of the .jsp > files is readily available so this bug is not critical. It still makes sense to > fix the bug if it is not too difficult. It looks as though the jsp file is > being read as a resource and separating the resources and jsp files into > separate directories may be one way to accomplish this. Might downstream adopters with their own help contributions have a different opinion?
(In reply to comment #14) Downstream adopters who write their own jsp files would definitely be affected by this vulnerability and separating the jsp and resource files in the help system would not solve that problem. I would be surprised if many users wrote their own jsp files and made them available on the help server but it's something to consider.
The bug here is not actually JSP specific and what happens is that when you ask for a resource at a path with \,(, or ) in it we will return the first file in the parent directory. This may or might not be the JSP as in my testing I had an HTML file returned because it came first in File.list(). Moving this to framework as we need to do some work in AbstractBundle.findEntries to better handle filter characters.
Note that * is not our friend either: http://help.eclipse.org/helios/advanced/* I think the complete fix is going to involve a change to the framework and the help system to sanitize the file pattern used. For the framework we must properly handle cases where '(' ')' '\' are part of the file pattern. As an implementation detail we use a Filter implementation to do the matching on the file pattern and here '\' '(' and ')' have special meaning. A '*' is used for wildcard matching. It is likely that the help system does not ever want to do wildcard matching. If a '*' is passed then the help system should escape the '*' with an escape char '\' so that the framework treats the '*' as a literal instead of as a wildcard. Also, the escape '\' is a special char and will be striped out of the filePattern for evaluation. An additional precaution that may be needed by the help system is to escape any '\' chars found. I'm not sure that is completely necessary or not since I cannot imagine anyone naming their resource files with a '\' char. For the framework we must ensure that we can construct a valid Filter with the filePattern. Currently if we fail this then the filePattern is essentially treated as a wildcard '*' which is bad. We should log this as an error and return nothing. In addition to that safeguard we really must do auto escaping for the '(' and ') chars. The javadoc for findEntries only specifies that '*' is a special char and there for it must be escaped if you don't want it to be treated as a wild card. Similarly '\' is a special char for escaping and it must be escaped if you don't want it to be treated as an escape. But '( and ')' should have no special meaning to findEntries. The use of a Filter implementation under the covers is an implementation detail and we should auto escape these chars for the user (in addition we should not auto escape them if they are already escaped by the user). I have a patch for the framework, but need to write some more tests before attaching the patch.
http://127.0.0.1:32172/help/advanced/tocView.jsp( is not processed by the help system, it is completely handled by the Equinox Web server.
Yes, Chris that's right -- nothing to do in Help. I'll add code to escape '*' in the appropriate HttpContext implementations at the same time.
I opened https://www.osgi.org/members/bugzilla/show_bug.cgi?id=1777 to update the OSGi Web Applications specification to advise implementers to sanitize the input before calling Bundle.findEntries.
Created attachment 181993 [details] proposed framework fix Here is a fix that auto escapes ( and ) if they were not already escaped. It also will fire an error event (that gets logged) if a syntax exception happens to occur and results in a null being returned from Bundle.findEntries. Finally it will throw an syntax exception if it detects an unescaped '\' char at the end of the file pattern. You are not allowed to have a trailing unescaped escape char '\' in a file pattern because there is no char left to escape.
This patch is against head, which has been restructured from 3.6. I opened bug328975 to consider backporting to 3.6.2.
*** Bug 329056 has been marked as a duplicate of this bug. ***
Created attachment 182067 [details] PoC screenshot
Created attachment 182068 [details] PoC screenshot
Created attachment 182069 [details] PoC screenshot
Created attachment 182070 [details] PoC screenshot
So, after all, is this bug due to OSGi or Eclipse's Adaptor to OSGi. I know this is not a security issue for Eclipse. Who else on earth is also vulnerable? This is the main concern, the reason why I reported this issue to Greg Wilkins. Let me know the answer. Thank you guys.
(In reply to comment #28) > So, after all, is this bug due to OSGi or Eclipse's Adaptor to OSGi. > > I know this is not a security issue for Eclipse. > > Who else on earth is also vulnerable? > This is the main concern, the reason why I reported this issue to Greg Wilkins. > Let me know the answer. Thank you guys. There are two bugs here. 1) The implementation of org.osgi.framework.Bundle.findEntries() does not properly sanitize the param passed to it for doing pattern matching on bundle content (or entries). This essentially can lead to behavior where the pattern matching param is treated as '*' or match all. This causes all entries in a particular directory to be returned instead of some subset, which the caller intended. 2) The implementation of HttpService, in equinox (that uses jetty) does not properly escape the '*' character when it calls the org.osgi.framework.Bundle.findEntries() method. Even with the fix to one you could still see the issue if you used a '*' char in your URL. 1) is a bug in the core framework 2) is a bug in the HttpService impl layer on top of the framework. Neither bug is in jetty.
Patch released to HEAD. I opened bug329193 for the remainder of the fix described in comment 19.
Created attachment 182140 [details] Proposed jsp and http registry fix Here is the Http Service side of the fix. To be clear the problem is not a general problem in the Http Service and only an issue when also using the http.registry to provide a resource lookup. I've also patched the JSP implementations use of findEntries to correctly escape the * and '\' although in that case source is not exposed and instead we'll hit an encoding problem inside of Jasper during compilation.
Patch released to HEAD and will update bug 329193
Created attachment 182148 [details] updated patch for framework. This patch uses the same optimization as Simon did for the jsp and http registry fix.
(In reply to comment #28) > So, after all, is this bug due to OSGi or Eclipse's Adaptor to OSGi. > > I know this is not a security issue for Eclipse. > > Who else on earth is also vulnerable? > This is the main concern, the reason why I reported this issue to Greg Wilkins. > Let me know the answer. Thank you guys. I will try to answer this again. This affects callers Bundle.findEntries that use a filePattern with unescaped characters which have special meaning to the OSGi Filter syntax (e.g. '(', ')', '\', and '*'). The characters '\' and '*' do have special meaning to the Bundle.findEntries. Callers of this method must escape '\' and '*' (with proceeding '\') if the caller requires these characters to be treated as normal characters. But callers must NOT be required to escape '(' or ')'. These characters have special meaning to the OSGi Filter syntax but must not have special meaning to the Bundle.findEntries method. So there are two bugs as I described in comment 29.
Is it time to remove the "committer-only" flag and make this patch known to the public?
*** Bug 387865 has been marked as a duplicate of this bug. ***
