Java Floating Point Bug Can Lock Up Servers

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."

Comments

Bullshit!

[Anonymous Coward]

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:Bullshit!

[Anonymous Coward]

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:Bullshit!

[Anonymous Coward]

>>> 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!

[the Atomic Rabbit]

There is no way this floating point thing is real.

It has to be real. Java lacks built-in support for complex numbers.

Re:Bullshit!

[prionic6]

Not only is it real, it is rational!

Re:Bullshit!

[lgw]

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.

Unless...

[MrEricSir]

...it's a critical bug in an Adobe product. Then it's going to linger for months, if not years.

Re:Unless...

[gstrickler]

Aren't Adobe products were simply a collection of bugs, artfully put together to form a useful, but slow and insecure program.

Re:About face!

[sixfive0two]

Actually, it's already fixed: Oracle has released a fix for this issue through Security Alert CVE-2010-4476. For more information see: http://blogs.oracle.com/security/2011/02/security_alert_for_cve-2010-44.html

Java, don't need it, don't want it!

[Anonymous Coward]

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

"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 "

Shocked! Shocked!

[curmudgeon99]

As a more than decade-long Java programmer, I must say that I am shocked! Shocked! that Sun would do something like that.
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?

[Tony Isaac]

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 going around with a device that emits this frequency, then it's time to come up with an antidote.

Java (like Mac OS) has enjoyed a relatively free ride, when it comes to malicious hackers. It's not that Java is somehow superior, it's just not been an attractive enough target. The fact that it is now being attacked is, in a way, a sign of its success.

Re:So what if they've known about it for 10 years?

[scdeimos]

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:So what if they've known about it for 10 years?

[ADRA]

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:So what if they've known about it for 10 years?

[Compaqt]

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:So what if they've known about it for 10 years?

[lgw]

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 how we pick on Java, not why we pick on Java.

Re:An infinite Java loop? Sounds interesting...

[PopeRatzo]

But I think I'll stick to running Folding@Home on all cores to burn in thermal paste.

Let me clue you in to a little secret: That's not really thermal paste...

Encountered this a couple years ago

[prehistoricman5]

I was working on a gas/billiard ball simulation a couple years ago and kept on running into a bug where the simulation would lock up in an infinite loop, and iirc, that magic number kept popping up. All along I thought it was some sort of bug in my code (it was a horrible hack job; it's almost unmaintainable).

Do NOT try this

[c0lo]

Try this:

• curl http://slashdot.org/

DO... NOT... TRY... THIS...

• curl -H "Accept-Language: en-us;q=2.2250738585072012e-308" http://slashdot.org/

Don't say I haven't warned you!!!!!

Fixed available

[Wookie Monster]

Oracle has posted a fix for the bug, in the form of a patch. Official releases will be available next week. http://www.oracle.com/technetwork/java/javase/fpupdater-tool-readme-305936.html http://blogs.oracle.com/security/2011/02/security_alert_for_cve-2010-44.html

Re:Cool!

[Anonymous Coward]

Thats the combination to my luggage!

It is not the JVM ....

[Chrisq]

The article makes it clear that the problem is in FloatingDecimal.java. It is converting decimal strings to floating point numbers - fp arithmetic is fine!

Re:It is not the JVM ....

[CynicTheHedgehog]

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:About face!

[petermgreen]

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:Fails to Work on Android

[atomice]

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

Re:About face!

[lgw]

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.