Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #328795 +++ 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.
Created attachment 182144 [details] 3.6.x patch
Simon please review for 3.6.2.
Created attachment 182149 [details] Updated 3.6.x patch Optimized patch.
Looks good.
Patch released.
Does this fix warrant a respin of any existing downloads? At what point do we remove the visibility restrictions?
(In reply to comment #6) > Does this fix warrant a respin of any existing downloads? Not in my opinion. The EPPs and eclipse builds this is not a big issue because all the source we include in EPPs and eclipse builds is open source and publicly available anyway. > > At what point do we remove the visibility restrictions? You should bring this up to the planning council. IMO we should not remove security restrictions until there is a publicly available fix that can be installed using the release train repos.
(In reply to comment #7) > > At what point do we remove the visibility restrictions? > > You should bring this up to the planning council. IMO we should not remove > security restrictions until there is a publicly available fix that can be > installed using the release train repos. Did anything come out of this at the PC? Helios SR2 has gone GA.
(In reply to comment #8) > (In reply to comment #7) > > > At what point do we remove the visibility restrictions? > > > > You should bring this up to the planning council. IMO we should not remove > > security restrictions until there is a publicly available fix that can be > > installed using the release train repos. > > Did anything come out of this at the PC? Helios SR2 has gone GA. Maybe John can answer that. My _personal_ feeling is that these should just stay restricted to the committer list.
(In reply to comment #8) > Did anything come out of this at the PC? Helios SR2 has gone GA. The subject has been raised in the architecture council but not yet resolved. See bug 337006.
(In reply to comment #7) > You should bring this up to the planning council. IMO we should not remove > security restrictions until there is a publicly available fix that can be > installed using the release train repos. Sorry... I should have made this connection earlier. I don't think it's up to the planning council. Really, it's up to you (the project) to decide how to handle these sorts of things. I suppose that you can make the decision in consultation with the PC if you (the project) determine that that is the best course of action. FWIW, it's not my intent to add a burden to the project. It is my experience, however, that any attempt to put project-directed decision making power into the PC, or the EMO will fail. I have posed some questions about disclosure on Bug 337006. My intent is to provide a handful of best practices (I've never liked that term) that projects can use for deciding how to disclose the vulnerability and fix. Your input on that bug would be appreciated. Personally, I believe that progressive disclosure is the best course of action. Are there any specific concerned parties (e.g. known adopters) who should be added to the bug to give them a heads up before we go public? Is this bug significant enough to warrant some kind of bulletin from the EF? Or is it just a bug that we can quietly make public and go about our business?
(In reply to comment #9) > My _personal_ feeling is that these should just stay restricted to the > committer list. I disagree. We can't just sit on this forever. Organizations who are affected by this vulnerability need to be given reasonable opportunity to mitigate their risk.
Is it time to go public with this vulnerability and corresponding patch?
I think the security keyword can be removed now as Wayne recommended 2.5 yrs ago :)
sorry - never mind. already cleared the security group. I mistakenly thought the keyword was blocking non-committer views.
