Bugzilla – Full Text Bug Listing
| Summary: | [Webapp][Security] Site redirection vulnerability in Eclipse Help System | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Darel Benysh <benysh> | ||||||
| Component: | User Assistance | Assignee: | Chris Goldthorpe <cgold> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | major | ||||||||
| Priority: | P2 | CC: | agarcher, cgold, curtispd, dejan, denis.roy, kleind, maguirem, Mike_Wilson, zhouyiy | ||||||
| Version: | 3.4 | Flags: | dejan:
review+
curtispd: review+ agarcher: review+ |
||||||
| Target Milestone: | 3.4 RC3 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=546430 | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Darel Benysh
Raising the priority to P2 and severity to major. Since this vulnerability has already been exploited it needs to be fixed. The problem affects infocenters - I think that the infocenter case is the only one that needs to be fixed but that is something that we can discuss here. For infocenters the only real solution is to not allow the raw topic parameter to be the URL for the content pane. Instead we should either call a function to filter out any urls which represent URLs outside of the help system and replace them with the URL of an error page or ignore the topic parameter completely in an infocenter - as far as I can tell there is no reason to use a URL with a topic parameter to access an infocenter. The topic parameter does have legitmate uses when the help system is called from Eclipse, for example when help is opened from Welcome, from a cheatsheet or from an infopop. I don't think any restrictions should be placed on use of the topic parameter when calling the help system from Eclipse because there are legitimate ways to use external URLs and because the vulnerability is a serious problem only for the infocenter. Dejan, Curtis what are your thoughts on this bug, particularly any risks involved? We are in RC3 now but this bug is serious enough that it may warrant inclusion. We should be careful to provide the fix in a way that does not break the existing infocenters. If they link to a page using a full URL it should continue to work as today. We should probably fix this using some kind of configuration parameter/preference for the infocenter that is placed in the plugin_configuraition.ini. The configuration parameter would offer several degrees of strictness (no external links whatsoever, same domain only, 'friendly domains' list etc.) I agree, I don't think we should disable the topic parameter for infocenters. It is fairly common practice to use the topic param to target into a specific page in an infocenter. I think infocenter solutions would either disallow full URLs within the topic paramter (http://....) or disallow URLs away from the host the infocenter is running on. Providing a configuration option to control the strictness would be a nice additional level to control the functionality. But it wouldn't be required to fix the hole. If there is a configuration option, the default should be fairly strict though. Seems like a reasonable precaution. Two things that will need to be tested are links to external pages in the toc or index (this is valid) and remote help. I don't think either of these uses this topic parameter but.. just in case. Good comments, here's my latest thoughts on this. I agree we need a preference to control whether the infocenter allows the topic parameter to be an external URL, the default should be to filter out the external URLs. A possible name for this preference is org.eclipse.help.base.restrictTopicParam. If the topic URL is external and we are running in restricted mode we can display the home page in it's place. An alternative would be to create a new error page to handle this situation but I don't think that is necessary. Eclipse and Standalone help should allow any value for the topic parameter - I don't think a preference is needed. The simplest implementation would be to disallow any URL starting with http: or https: when in restricted mode. This would also disallow URLs which happened to be on the same server as the help system but I don't see that as a situation that is going to arise in normal usage. Created attachment 102421 [details]
Patch
Here is a patch which adds a preference org.eclipse.help.base.restrictTopicParameter. If true the infocenter will show the home page if a topic parameter starting with http: or https: is passed in.
The one aspect of this patch which needs to be considered carefully is whether this the right test to be performing, will it be sufficiently restrictive to filter out any abusive URLs and conversely is it overly restrictive in a way that would impact legitimate uses in which case I will revise the patch.
I have no doubt that we need to fix this problem, I just want to make sure that I get the details right.
I would make it a case-insensitive check, just in case (my browser accepts uppercase HTTP:// urls). Also, one question I have (and don't know the answer to) is whether we should worry at all about other protocols, like ftp:/. I agree with restricting any URL which starts with a protocol, I can't think of a valid reason for using any other protocol in the topic parameter. There probably is some other protocol that could be used maliciously - better to make the restricted mode only allow paths without protocol. Created attachment 102517 [details]
Patch version 2
This patch restricts any value for the topic parameter which has a protocol. The restriction is enforced only in infocenter mode and can be overridden in preferences.ini.
I have released the patch to HEAD. I will set the state to fixed once I've updated the docs. The docs have been updated. Marking as FIXED. Verified in eclipse-SDK-I20080530-1400-win32 by Yi Yan Zhou. If this is fixed we can remove the bug from the closed Security group? Yes, I agree. Clearing the security flag. |