Java Floating Point Bug Can Lock Up Servers 157
An anonymous reader writes "Here we go again: Just like the recently-reported PHP Floating Point Bug causes servers to go into infinite loops when parsing certain double-precision floating-point numbers, Sun/Oracle's JVM does it, too. It gets better: you can lock up a thread on most servers just by sending a particular header value. Sun/Oracle has known about the bug for something like 10 years, but it's still not fixed. Java Servlet containers are patching to avoid the problem, but application code will still be vulnerable to user input."
About face! (Score:1)
Betcha it'll be fixed tomorrow!
Re: (Score:2)
Unless... (Score:3)
...it's a critical bug in an Adobe product. Then it's going to linger for months, if not years.
Re:Unless... (Score:4, Insightful)
Hex. (Score:2)
The supercomputer Hex. [lspace.org] Only at the Unseen University. "Anthill Inside"!
Re: (Score:2)
damn, i ran out of mod points yesterday. +3 Insightful to you, +5 Funny
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Why would Adobe *fix* bugs? They're hard at work on a new version, with entirely new bugs. And you can pay $500+ for the privilege of being in their testing department, knowing crash reports get sent straight to /dev/null.
Re: (Score:2)
Or get your ass sued for daring to reveal long-standing bugs that the assholes that maintain it have consistently refused to fix.
Re: (Score:2)
Re:About face! (Score:4, Insightful)
Yeah bugs that pop up every so often to end users (and are common enough or reported by trusted enough users that they can't just by dismissed as coming from liers/trolls) but only pop up sporadically and/or only pop up on certain systems are a big problem for developers. With no reliable way to reproduce a bug it is almost impossible to fix it.
Even more irritating are the bugs that dissapear as soon as you try to use a debugger.
The firefox memory and CPU usage issues are good examples of this. Way too many users reported them to dismiss them as a lie or fluke but there was no set of steps to reproduce. Every so often one cause was found and squashed but they kept coming up for years and may still be doing so (I still see firefox crash for no apparent reason and it wouldn't surprise me if the cause is running out of address space).
Re: (Score:3)
Even more irritating are the bugs that dissapear as soon as you try to use a debugger.
We call those Heisenbugs, as obsering them changes the result.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Informative)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
That bug from 2000 reports an issue in the parsing code but doesn't appear to be a DOS like the one under discussion here.
Bullshit! (Score:4, Funny)
Java is a secure virtual machine environment. Programs never crash and low level errors like pointer or memory problems are impossible. There is no way this floating point thing is real.
Java is the future and you are retarded. Java is the fastest programming language ever invented, that's why it's the primary language we learn and teach in school.
I have been a HTML programmer for many years, I know what I'm talking about.
Re: (Score:2, Funny)
That's why it's used to implement all video codecs!
Re: (Score:2, Informative)
Actually, this is not a security bug allowing someone to break into the server or run their own code. The only possible exploit is using up CPU time. If a server is setup properly, it will not lockup the machine, but it still allows an easy vector DoS against the application and/or application server.
Re: (Score:2)
It is still quite critical for anyone who develops internet accessible apps using Java. One person can DoS your entire system with some bad data.
Re: (Score:2)
It doesn't matter much if the box is running or not; if the application server that is the reason for the box isn't, the server is considered down.
That it's so incredibly easy to exploit is another issue.
Allegedly, the following works against most web servers that accept different languages:
Then there are form fields which accept doubles. Including a lot of payment forms.
Re: (Score:2)
DOS is classified as a security issue.
Depends on the deployment configuration. It's often quite easy to mitigate DoS attacks that only hit a single layer of the overall architecture (e.g., by replicating servers and adding a watchdog that restarts things if they go unresponsive for too long). The tricky ones are those that involve many levels, especially if they just look like lots of normal traffic.
Re: (Score:2)
So is Windows, but they keep selling it anyway.
Re: (Score:2, Funny)
>>> is no way this floating point thing is real.
Are you insinuating an int thing is real, if floating point thing is not real?
Re:Bullshit! (Score:5, Funny)
It has to be real. Java lacks built-in support for complex numbers.
Re: (Score:3)
Not only is it real, it is rational!
Re: (Score:2)
I take Computer Science III [encycloped...matica.com], I know what I'm talking about.
Fixed that for you Mike.
Re: (Score:2)
Re: (Score:2)
No real-world computing environment is Turing complete (because memory is finite), and provability of termination is in theory possible for all common languages in real-world computing environments (because memory is finite). And in the real world, getting an inifinite-loop bug out of floating-point routine just isn't that hard.
Denial of service attacks are real attacks, BTW. If some random script kiddy can just turn your business off, chanse are you care. This one is probably easy to mitigate, but as a
Re: (Score:3)
Also, making italics work on the internet just isn't that hard. Maybe Slashdot needs to hire some of those aforementioned script kiddies, or some chimpanzees, or something like that to improve the "Slashdot 3.0" experience - they could hardly do worse.
Re: (Score:2)
Re: (Score:2)
My termination inspections are the guy sitting next to me, and vice versa. This is just the kind of problem that code review is good at finding - at leats, given experience reviewers. I don't know what those shops where everyone is under 25 do.
And how soon was the PHP bug fixed again ? (Score:1)
Re: (Score:1)
The PHP bug was reported on Dec. 30 and fixed I think on Jan. 3, which is 5 days. I'm pretty sure it doesn't take a time machine to make a one-line fix that quickly!
dom
Re: (Score:2)
The PHP bug was reported on Dec. 30 and fixed I think on Jan. 3, which is 5 days.
Yow! 5 days.
I wonder what happened between Dec 30 and Jan 3? Anything that might of distracted the developers?
Re: (Score:2)
I've solved it! (Score:1)
I've already found the solution to this. Just patch Java to avoid the Pentium FDIV bug! I mean, those Java people are still using Pentiums, right? They claim Java is fast, so it must be the CPUs! Why else would the bug be around for so long?
An infinite Java loop? Sounds interesting... (Score:2)
Re: (Score:3)
Let me clue you in to a little secret: That's not really thermal paste...
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Don't you see? It's a feature! (Score:1)
Java, don't need it, don't want it! (Score:2, Insightful)
I now uninstall Java from any systems I work on as a security precaution. The auto-update is a nice 'feature', but in most client's systems I work on, none of them have any compelling reason for an installation of Java.
Over two years and no fix for Java [h-online.com]
"Sami Koivu has released details of a security vulnerability in Java which he reported to Sun in 2008. A quick test using the current version 1.6.0_23 reveals that it remains unpatched "
Re: (Score:1)
I now uninstall Java from any systems I work on as a security precaution.
After cleaning up a virus that came via Java I do the same for people who's computers I work on. Most people really don't need it and it's hard to keep fully patched, not to mention all the zero-day vulnerabilities.
Re: (Score:2)
Java is among the many plugins I disable in Firefox. One of the first things I do. Firefox updates are frequent enough to be secure but the plugins is where the problems are.
Shocked! Shocked! (Score:5, Funny)
Why, I'd go so far as to predict that a company that behaved that way would find itself out of business.
Hey, wait a second...
So what if they've known about it for 10 years? (Score:2, Interesting)
Does Java software crash all the time because of this bug? No, of course not, that's one reason Java software is useful at all.
Like with any software, it is essential to prioritize bug fixes. You deal with the bugs that bite you, and save the rest for later.
This is a valid principle for anything made by people, not just software. Somebody might find out, for example, that if you subject a window to a specific frequency of sound, the window will shatter. So what! Don't do that! But...if burglars start
Re: (Score:3)
Somebody might find out, for example, that if you subject a window to a specific frequency of sound, the window will shatter. So what! Don't do that! But...if burglars start going around with a device that emits this frequency, then it's time to come up with an antidote.
Except that the resonant frequency of the windows in your example is dependant upon their volume and mounting frames - thus making it different from window to window. Being able to crash all sorts of Java programs by throwing a certain number at them is a little more repeatable.
Re: (Score:3)
Repeatable yes, but that also requires programs to have well known and easily deliverable raw floating point number insertion points. Some will have tons and others won't have any. It seems analogous to the window flaw after all.
Re: (Score:2)
"Java sucks less because people use it less". Sounds reasonable.
Re: (Score:2)
It's also not true - all JSP sites render as Servlets, as I think most Java web technologies do.
Re: (Score:2)
The same goes for available software. Compare the number of open-source web frameworks and content management systems available for the two languages. Java is barely a blip. PHP is everywhere, and python and ruby are follow-ups.
Re: (Score:2)
Which doesn't change the fact that PHP is more widely used on the web than Java.
That may be true but you sure didn't prove it here.
Pretty much every web hosting project offers a basic LAMP or WAMP stack. Java? Not so much.
I agree, especially Google's App Engine which...oh wait.
Anyway, your point is that for cheap web hosting PHP is more common and that PHP rules the least common denominator of web sites. Tell us something we didn't know.
The same goes for available software. Compare the number of open-source web frameworks and content management systems available for the two languages. Java is barely a blip. PHP is everywhere, and python and ruby are follow-ups.
Great! But the relevance is, s you like to say, "not so much" to your argument.
If you measure by number of .php pages out there, yes, there's more PHP on the net than Java. If you measure by bajillions of web pages served, it's probably th
Re: (Score:2)
They probably serve more pages than all the java servlets combined.
Re: (Score:2)
http://www.facebook.com/login.php [facebook.com], yahoo (and Steve Ballmer said that if they had bought Yahoo, Microsoft would have been the biggest user of php on the net), http://photobucket.com/index.php [photobucket.com], digg, etc. Even the white house's site http://whitehouse.gov/ [whitehouse.gov] runs php.
Not too many large sites use Java. Mostly corporate e-payment systems.
Re: (Score:2)
Are you shocked that people who have an axe to grind about Java are using this to criticise the language? Has slashdot *ever* given Java a fair go? I think not.
Re: (Score:3)
The problem that any Real Programmer has with Java is not how the language works - there's always a place for a language with the sharp corners rounded off. The problem is Java is the new COBOL - the language in which all the most boring programming jobs in the world get done by business school graduates. You can do cool things in any language, but if you're doing the least cool things, chances are you're doing them in Java. Any criticism of details of the language are sort of an afterthought - they're h
Re: (Score:2)
because its impossible to do anything this dangerous or insecure in C++
Re: (Score:2)
No it does not crash all the time, but given that i am a server framework programmer this issue is severe enough. It is not funny if a well placed http get parameter can shoot down your entire server. It of course depends on the backend code really trying to convert the number into float params. So far Tomcat has fixed this relatively quickly other frameworks as well ( you still can shoot down the server on framework level)
But the final fix has to come from Oracle.
Re: (Score:2)
Actually it's PHP that powers most internet sites, but thanks for playing.
Re: (Score:2)
Yeah, sure, all those banks, Google, Twitter... PHP through and through.
PHP powers a *lot* of small hack websites. If running forums is your idea of the important parts of the web, then sure, yeah PHP powers a tonne of that. Java powers things that are actually used on an industrial scale, require reliability and security.
Re: (Score:2)
Well, there's Wikipedia, Facebook (converted to C++ with HipHop, but still) and Flickr.
Re: (Score:2)
Yeah, sure, all those banks, Google, Twitter... PHP through and through.
Google uses everything.
Twitter started with ruby on rails, then moved to Ruby on Rails to deliver most user-facing web pages, and some of the back-end Ruby services with applications running on the JVM and written in Scala [artima.com].
Re: (Score:2)
Actually it's PHP that powers most internet sites, but thanks for playing.
It's not clear who the bigger player is -- php or java -- but both are huge.
And he didn't say "most internet sites" -- he said "majority of major internet sites" -- a subjective measure which makes such a claim difficult to prove or disprove.
Re: (Score:2)
So which large sites use Java to power their site ?
Re: (Score:2)
So which large sites use Java to power their site ?
Ebay [highscalability.com]
Amazon uses it, among other things [highscalability.com]
google uses it, among other things [highscalability.com] (you name it, they probably use it somewhere)
Lots of corporate sites, intranet and extranet, use java. Java is extremely strong there. Some of these sites are small, some are huge.
Ultimately, most sites hide what language they're written in -- you have to go looking for it. To be more precise, they don't intentionally hide it, it's just that their sites tend to not make it obvious. (php is often more obvious than many others, howe
Re: (Score:2)
"major sites" ? well, let's see Alexa top 1000 or something like that.
Ebay uses it at the frontend, I didn't know that. But Google and Amazon don't. Amazon and Facebook use it for certain parts.
Re: (Score:2)
Re: (Score:2)
Not to be picky, but he was talking about the majority of _all_ major sites, not the top ten. Still probably not true, but it should be a significant percentage.
Also, while not primarily powered by it, Google and Facebook (and probably others on the list, don't know) use Java in some of their backend systems. According to a quick internet search.
Re: (Score:3)
Well, Facebook and Yahoo. Those are pretty big.
Yes, they're running other stuff, too, but PHP as well in a big way.
Not saying that Java's not important, but PHP is probably going to become more prevalent in large websites simply because garage tinkerers often start in PHP, the site becomes big, and they're still on PHP.
I'm also not saying anybody should run banking on PHP (please don't do that), but for serving up webpages? Yeah.
Re: (Score:2)
you're joking, right? Fixing a infinite loop caused by normalization of certain values should have the highest priority, that's a broken math library in the planet's platform for doing enterprise math. The ten year old bug report not only gave the range of numbers but the follow up to it even included the fix. Too bad slashdot's lameness filter doesn't allow reproducing it here
Ditto. The fact that Oracle shelved this bug for *A DECADE* is incredible, specially considering the exposure Java has as a platform and that the original poster actually bothered to include a one-line patch solving the issue entirely.
Encountered this a couple years ago (Score:2, Interesting)
Do NOT try this (Score:4, Funny)
DO... NOT... TRY... THIS...
Don't say I haven't warned you!!!!!
Re: (Score:2)
Isn't slashcode written in perl rather than java?
Oh ... I see what you did there!
Re: (Score:2)
Actually, it looks like they use Varnish as a kind of loadbalancer.
Fixed available (Score:5, Informative)
Re: (Score:2)
A fix in form of a patch has been posted on the 10 year bug report of the same bug. Didn't seem to like that helped a fix find its way into Java.
Fails to Work on Android (Score:2)
Re: (Score:2)
Guess they simply used the Harmony Code for this stuff and Harmony does not have the bug in.
Re: (Score:2)
Guess they simply used the Harmony Code for this stuff and Harmony does not have the bug in.
It was fixed in Harmony a year and a half ago:
https://issues.apache.org/jira/browse/HARMONY-329 [apache.org]
Re: (Score:2)
If it's the same problem PHP had, then it requires an x86 FPU.
Re: (Score:2)
Re: (Score:2)
If it's the same problem PHP had, then it requires an x86 FPU.
It is not. Both bugs are similar in the sense that they're triggered by some border cases of floating-point values, but are otherwise completely unrelated.
It is not the JVM .... (Score:5, Insightful)
Re:It is not the JVM .... (Score:4, Informative)
I haven't used floats or doubles in a long time. From a business perspective (think monetary values) it almost always makes more sense to use BigDecimal and apply rounding rules, particularly if those values are stored in a database where scale and precision are known or required. I would imagine the same would be true for scientific values, GIS coordinates, etc. (anything with a known precision). The only use for float/double that comes to mind is something where absolute precision isn't critical and speed is important, such as graphics/physics calculations for games, in which case you generally wouldn't be parsing user-entered values anyway.
Also, the default/packaged JSF numeric input converters produce either Long or BigDecimal values (per spec) depending on whether a decimal is present, so this should only affect a very small subset of use cases that are easily patched or avoided (old JSP/servlet code, Struts, etc.)
Re: (Score:2)
Also, the default/packaged JSF numeric input converters produce either Long or BigDecimal values (per spec) depending on whether a decimal is present, so this should only affect a very small subset of use cases that are easily patched or avoided (old JSP/servlet code, Struts, etc.)
Do you really think that "old JSP/servlet code" is rare? Systems that pre-date JSF popularity are the norm.
Re: (Score:2)
Well, technically all JSF apps are also servlet-based, and I was initially concerned that everything was affected based on comment #53 in the source article, but I tried the header on my local applications with no ill effects (my application does use resource bundles and would by necessity look at the locale headers). I also looked at jmx-console and web-console to make sure they were okay--these are by and large basic servlet/JSP apps. (JBoss 5.1, Java 1.6.0_22 64 bit.)
The JVM itself is definitely affect
Re: (Score:2)
There are many areas where the overheads of arbitrary-precision arithmetic are not acceptable. There are also areas where arbitrary-precision arithmetic is not good enough, and systems that formally deal with irrational numbers like or 3 or rationals like 1/3 with recurring binary and decimal representations. Mathematical formulas to ensure that roundoff errors [wikipedia.org] are well conditioned and don't accumulate are well understood by people who have complex computational needs.
Your assertion that you can "just us
Re: (Score:2)
I said BigDecimal is appropriate for most business use cases, especially when dealing with money, as you can control the precision and rounding behavior. The problem with floating point formulas is that they don't always round in the way you want or need them to. If you've ever applied percentage discounts and then added up the results you will see that iusing float or double often causes you to be off by one or two cents. Here [blogspot.com] is a good post on the problem with relevant examples.
Stated another way, if y
Re: (Score:2)
The last part of the above post is actually incorrect. (javax.faces.convert.NumberConverter) uses DecimalFormat, which by default produces either a Long or a Double depending on whether the value fits into a Long. You can call DecimalFormat.setParseBigDecimal to make it use BigDecimal, though. Also, DecimalFormat does some digit manipulation via DigitList before calling Double.parseDouble. So Double.parseDouble("2.2250738585072012e-308") is affected, but new DecimalFormat.parse("2.2250738585072012e-308"
Re: (Score:2)
No. Unconstrained user input will be. If you're not already checking the user input before passing it along, you're a fucking idiot and this bug is the LEAST of your worries.
There are a few niche cases, like calculators and spreadsheets, where the constrained input could validly include the input. The assertion in comments to the article that quality values in HTTP headers cause this problem do not come into this category, as the standard [w3.org] says that only three digits after the decimal should be sent.
Re: (Score:2)
And how is an application supposed to check user input? The normal way to check a user-provided floating-point value for validity is to call Double.parseDouble() [oracle.com] and catch the NumberFormatException that's thrown if it can't be parsed, then apply any relevant range checks using mathematical operations. The documentation for that method doesn't say anything about entering an infinite loop; it can either return a double, or throw an exception.
An alternative would be to use regular expressions. There might be
Re: (Score:2)
Re: (Score:2, Funny)
Re: (Score:2)
Wont help :-) it only triggers if the text field parses for a floating LONG number!
Most textfields either go for Int or Float as their targets.
Re: (Score:2)