Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Java Oracle

Java Floating Point Bug Can Lock Up Servers 157

Posted by Roblimo from the here-a-bug-there-a-bug-everywhere-a-bug-bug dept.
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."
This discussion has been archived. No new comments can be posted.

Java Floating Point Bug Can Lock Up Servers More

Java Floating Point Bug Can Lock Up Servers

Comments Filter:

  • Sun/Oracle has known about the bug for something like 10 years, but it's still not fixed.

    Betcha it'll be fixed tomorrow!

    • It's amazing how fast public disclosure can get bugs fixed.

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

      • 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)

        by DrXym ( 126579 )
        Actually it's more amazing how a well described, reproducible error which illustrates a security flaw gives rise to a fix. Sounds like the previous bugs were too vague to isolate the issue. Bug databases always end up with bugs like that. Go look how many bugs Firefox has open on it for example.

        • Re:About face! (Score:4, Insightful)

          by petermgreen ( 876956 ) <plugwash@p[ ]ink.net ['10l' in gap]> on Wednesday February 09, 2011 @08:23AM (#35149342) Homepage

          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)

            by lgw ( 121541 )

            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.

            • Those are a whole lot of fun in real-time, event driven systems. Slow things down by tracing the code and the problem doesn't occur anymore.

    • Re: (Score:3, Informative)

      by sixfive0two ( 1984966 )
      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 [oracle.com]
      • Like I said, it's amazing how fast public disclosure can get bugs fixed. Even ones that have been known for 10 years.
        • Bug ID 4399272 trumps the one mentioned in the article and was logged 08-Dec-2000. As with 4421492 it's no longer available on the Sun site, but it's still in Google's cache [googleusercontent.com].

          • 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)

    by Anonymous Coward on Tuesday February 08, 2011 @10:15PM (#35146464)

    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)

      by Citizen of Earth ( 569446 )

      Java is the fastest programming language ever invented

      That's why it's used to implement all video codecs!

    • Re: (Score:2, Informative)

      by 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: (Score:2)

        by AmiMoJo ( 196126 )

        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)

        by arth1 ( 260657 )

        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:

        curl -H 'Accept-Language: en-us;q=2.2250738585072012e-308' $URL

        Then there are form fields which accept doubles. Including a lot of payment forms.

    • Re: (Score:2, Funny)

      by 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! (Score:5, Funny)

      by the Atomic Rabbit ( 200041 ) on Tuesday February 08, 2011 @11:32PM (#35147054)

      There is no way this floating point thing is real.

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

    • I take Computer Science III [encycloped...matica.com], I know what I'm talking about.

      Fixed that for you Mike.

    • I realize your post was intended to be +100 Funny, but for the record, it's fairly hard to invent a language which is both Turing-complete and provides for provability of termination. (A non-converging loop is the source of this float parsing bug). In computer science we tend to call that the halting problem. Also, FWIW, these class of problems don't generally lead to exploits outside of denial-of-service attacks.

      • Re: (Score:2)

        by lgw ( 121541 )

        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)

          by lgw ( 121541 )

          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.

        • If we're talking about the real world, where are my termination inspections in my IDE? Nobody said denial of service attacks aren't real, but there are different paths for dealing with them. I say this being just a little familiar with preventing arbitrary code from running wild on machines.

          • Re: (Score:2)

            by lgw ( 121541 )

            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.

  • dont answer - it wasnt even a day. a shorter fix would only be possible with a time machine.

    • Re: (Score:1)

      by Anonymous Coward

      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

      • 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?

      • Five days to look into a low level problem and verify it. It is my understanding that low-level issues like this could have a large impact. So more than one person would probably be involved in discussions of the problem and the fix. Then testing. All during the holiday season. All of it done by volunteers. I'd say that was good service.

  • 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?

  • But I think I'll stick to running Folding@Home on all cores to burn in thermal paste. Seems more productive, you know?

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

      • Well, if it's not thermal gel, thermal compound, thermal paste, heat paste, heat sink paste, heat transfer compound, or heat sink compound, then I don't know what it is. Although if you spend enough time messing with it, I do know it makes a wonderful contraceptive - as G/Fs get tired of being ignored and move on.
      • it's made of people?!
    • How slow is an infinite loop in Java? Now much memory does it take to execute?
  • Write once, exploit anywhere!

  • Java, don't need it, don't want it! (Score:2, Insightful)

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

    • 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)

      by Lennie ( 16154 )

      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)

    by curmudgeon99 ( 1040054 ) on Tuesday February 08, 2011 @10:58PM (#35146816)
    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...

  • 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

    • 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)

        by ADRA ( 37398 )

        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.

    • Actually, as one of the comments on the site pointed out:

      I think this bug is less critical than PHPâ(TM)s bug, because Java Servlets are not used as much as PHP

      "Java sucks less because people use it less". Sounds reasonable.

      • Re: (Score:2)

        by kaffiene ( 38781 )

        It's also not true - all JSP sites render as Servlets, as I think most Java web technologies do.

        • Which doesn't change the fact that PHP is more widely used on the web than Java. Pretty much every web hosting project offers a basic LAMP or WAMP stack. Java? Not so much.

          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)

            by afabbro ( 33948 )

            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

            • Facebook is now the #1 site in terms of pages served (beating out google) and they use PHP, not Java.

              They probably serve more pages than all the java servlets combined.

    • Re: (Score:2)

      by kaffiene ( 38781 )

      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)

        by lgw ( 121541 )

        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

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

  • 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 (Score:4, Funny)

    by c0lo ( 1497653 ) on Tuesday February 08, 2011 @11:32PM (#35147048)
    Try this:

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

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

  • Fixed available (Score:5, Informative)

    by Wookie Monster ( 605020 ) on Wednesday February 09, 2011 @12:21AM (#35147302)
    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 [oracle.com] http://blogs.oracle.com/security/2011/02/security_alert_for_cve-2010-44.html [oracle.com]

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

  • The code works fine on Android. Guess that they are not running a true JVM.

  • It is not the JVM .... (Score:5, Insightful)

    by Chrisq ( 894406 ) on Wednesday February 09, 2011 @03:52AM (#35148204)
    The article makes it clear that the problem is in FloatingDecimal.java [docjar.com]. It is converting decimal strings to floating point numbers - fp arithmetic is fine!

    • Re:It is not the JVM .... (Score:4, Informative)

      by CynicTheHedgehog ( 261139 ) on Wednesday February 09, 2011 @09:03AM (#35149700) Homepage

      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)

        by meloneg ( 101248 )

        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.

        • 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)

        by Chrisq ( 894406 )

        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

        • 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

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

Slashdot Top Deals

As the trials of life continue to take their toll, remember that there is always a future in Computer Maintenance. -- National Lampoon, "Deteriorata"

Close