Community
Participate
Working Groups
By chance ... well, you know, in the course of my travels ... I happened upon a security advisory Oracle Security Alert for CVE-2010-4476 http://www.oracle.com/technetwork/topics/security/alert-cve-2010-4476-305811.html I guess this has been "public knowledge" since Feb 8, 2011. (I first saw the notice on one of my companies internal sites ... but it referenced the public alert, above). In short, a simple, but very specific, Java method call can cause an infinite loop, thus causing Java crashes or denial of services. Double.parseDouble("2.2250738585072012e-308"); I'm not exactly sure how some malicious person could take advantage of this, but the alert says "it may be exploited over a network without the need for a username and password" ... so, sounds kind of serious ... worth attention. And ... the point of this bugzilla report ... the "default" java, at least from a build.eclipse.org shell, is old enough to still have this vulnerability. java -version returns java version "1.6.0_20" Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) and apparently you need to be greater than 1.6.0_23. I actually ran a small test program I wrote that verified the vulnerability exists in the default java (that is, apparently, our default version of java has not been patched, or anything). I won't attach the jar unless requested, since, I don't want to leave my finger prints on a jar that exploits a security vulnerability :) ... but, also because I suspect there are better ones available (well, there was from IBM, from that internal site ... so, assuming there would be some public one). My test code simply "hung", by executing this simple Java code in a main method: public static void main(String[] args) { System.out.println("about to call Double.parseDouble(\"2.2250738585072012e-308\"); "); double result = Double.parseDouble("2.2250738585072012e-308"); System.out.println("the call returned. Must not have hung"); } So, my advise, is to use the patch tool referenced in the above advisory link to fix the default java that is installed with our Eclipse.org SUSE Server 11 distribution ... and any other obvious ones that are routinely used in Eclipse services, such as running Hudson ... but, IMHO, I don't think anything anything special needs to be done to all the versions in /shared/common ... since those are presumably only used by committers to do special tasks or tests and this vulnerability would be near impossible to hit by accident. Or, alternatively, I guess you could update the java's to the latest versions ... but, then I guess you'd get lots of changes. Or, alternatively, guess you could maybe find a SUSE "fix" for this, but only one I found did not mention Sun's VM ... such as http://www.compatdb.org/forums/topic/75248-security-announce-suse-su-20110823-1-important-security-update-for-ibm-java-142/ So, just wanted to bring this to your attention. I don't think it is an emergency fix sort of problem, or anything. It caught my eye since Java related, and looked interesting that such a simply method method call (in a core Java class) could cause the problem. I hope this report is helpful. Thanks.
Thanks for the report. Our java packages come from SuSE, so I'm surprised they haven't patched this yet. If I didn't trust our committers, who have the ability to write and run code on our servers, I'd be patching this myself. In this case, someone would have to be able to inject that value into running code for that code to crash. Perhaps help.eclipse.org and hudson present a higher degree of vulnerability, but both of those crash often enough on their own without external help that it doesn't make a difference :-D I'll track down the CVE with Novell to see where they're at.
What is our status? Is it time to remove the "committers-only" flag? Do we consider this an "Eclipse" security flaw? (i.e. should we add the "security" flag to this bug?)
(In reply to comment #2) > Do we > consider this an "Eclipse" security flaw? (i.e. should we add the "security" > flag to this bug?) I thought we should, simply because if there is an "app" somewhere, (help? hudson?) that under the covers does a Double.parseDouble(...) with user input, then Eclipse would be vulnerable. I know of no way to determine that ... though admit it would be unlikely ... so think it is "advertising" the potential vulnerability, unless/until we now the JREs are the up to date patched versions.
We have a bunch of old JRE/JDK installs in /shared/common which are likely vulnerable. We'd have to consider purging those too.
Since this apparently doesn't require any attention or fix ... I'm going to close as "won't fix". I would not make it "open", though, since that'd just be broadcasting the "challenge" that there might be an exposure somewhere. Feel free to re-open if I have misunderstood.
I'm not sure why you would close a webmaster bug as WONTFIX. From my previous comment, there are a bunch of older Java VMs kicking around on /shared. All of them are likely vulnerable, but none of them are likely going to be patched. Since we can't just remove them (since we'll likely break something), how do you suggest we fix this?
(In reply to Denis Roy from comment #6) > I'm not sure why you would close a webmaster bug as WONTFIX. > Sorry, I misunderstood. I thought you said once a security bug that doesn't have to be fixed in a month, doesn't need to be fixed -- bug 411132 comment 5. I closed it as it just happened to pop up on some other queries I was doing, so thought I'd be "helpful" and close it since it was so old. (And, since I opened it.) > ..." none of them are likely going to be patched" Sounds like "won't fix" to me. I do not know of anyway to fix this, other than what Oracle recommends.
Can't argue with that. I re-read the CVE, and all it can do is crash. If someone manages to exploit this and begins crashing some web app, we'll deal with it then. "Successful attack of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete Denial of Service) of the Java Runtime Environment. Java based application and web servers are especially at risk from this vulnerability." Bug 411132 does expose a larger concern of maintaining older versions of Java on /shared, but again, should a security vulnerability be discovered that puts us at greater risk, we'll do what we need to do to eliminate the risk then deal with the wake.
> I would not make it "open", though, since that'd just > be broadcasting the "challenge" that there might be an exposure somewhere. I'd do the opposite -- I'd invite someone to write some code that exploits it, submits it to Gerrit where it gets picked up by the Gerrit plugin, builds it, executes it, and successfully takes down Hudson or a HIPP instance. If no one can do that, maybe I'll change my mind that the Gerrit plugin is pure madness.
