Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #320424 +++ Bug 320424 contained two different issues and has been split into two clones to cover each of the problems. This is the url to reproduce (on Windows) http://localhost:1258/help/topic/file:/c:/
After further investigation I discovered that there is code in EclipseConnector which blocks this path if the client and server are not the same IP address. This means that the vulnerability is limited in it's ability to be exploited although it should still be fixed. Provisionally targeting 3.6.1.
Created attachment 174998 [details] Patch This patch removes the code which allows /topic/file: to be processed as a read of the server file system and also removes code which converts file: to /topic/file: when requesting the open of a URL.
Created attachment 175082 [details] Improved patch
Here are some notes on the bug based on my investigation: /topic is handled by the class ContentServlet, which calls EclipseConnector.transfer() to perform a read. transfer() calls getURL(req) to get the “url” to be used to read the data. This url could be of the form plugin/path or of the form protocol:/path EclipseConnector() has code to prevent any of the protocols file:, jar: or platform: from being allowed if in infocenter mode. In non infocenter mode any of those three protocols is permitted. If the path does not contain a protocol the help: protocol is used. A connection is created using the protocol specified. There are legitimate uses of the file: and jar: protocols in Eclipse, opening Javadoc is the one that comes to mind. I’m not sure where the platform protocol is used, if at all. For Javadoc in an uncompressed folder a url like this is generated: file:/C:/downloads/sunjre/jdk-6u18-docs/docs/api/java/lang/String.html?noframes=true For a zip file this kind of URL is generated: /jar:file:/C:/downloads/sunjre/jdk-6u18-docs/docs.zip!/docs/api/javax/xml/parsers/DocumentBuilder.html?noframes=true The solution in the patch prevents /topic/file: from be processed as file: on the server. There is also some code to allow calls to BaseHelpSystem which use the file:protocol to continue to work.
I have committed the patch to HEAD. Still need to commit to 3.6 maintenance stream.
This prevents the vulnerability in my tests.
Chris, can you explain why we also check "index == 1" in org.eclipse.help.internal.base.BaseHelpSystem.isFileProtocol(String)? Why do we get an empty page instead of "Topic not found"?
The reason for "return ( index == 0 || index == 1 );" in BaseHelpSystem.isFileProtocol is that there is code in BaseHelpSystem.resolve() which handles both the case where the path begins with a slash and the case where it does not, in which case it adds one when generating a help URL. I don't know if there is a path to get to this code with an href staring with /file: but to be on the safe side I have tested for that also. The reason there is no "Topic not found" page returned from the help system is that this page is only generated for requests for pages which end with any of the extensions "htm","pdf","xhtml","shtml" or "html". If a nonexistent file with another extension such as .css or .img is requested a 404 status is returned. If you open http://localhost:1258/help/topic/file:/c:/ in IE you see the HTTP 404 not found page, in Firefox you see a blank page but I can see in Firebug that 404 was returned.
>which handles both the case where the path begins with a slash and the case >where it does not Then we should test for index == 0 || index == 1 && charAt(0) == '/' and add a comment. With these changes the patch is good for 3.6.1.
Created attachment 176683 [details] Patch including Dani's suggested changes
Patch including Dani's fix has been applied to the 3.6 maintenance stream. The same fix is also in HEAD. Fixed
The patch has been applied to the 3.5 maintenance stream
Verified in M20100901-0800
Removing security restriction for bugs that have been fixed in 3.6.2 or earlier.
