Slashdot Mirror


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

157 comments

  1. About face! by Citizen+of+Earth · · Score: 0

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

    Betcha it'll be fixed tomorrow!

    1. Re:About face! by gstrickler · · Score: 1

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

      --
      make imaginary.friends COUNT=100 VISIBLE=false
    2. Re:About face! by sixfive0two · · Score: 3, Informative

      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

    3. Re:About face! by Anonymous Coward · · Score: 0

      Well, fast, good, or cheap: pick any two.
      And Java is pretty cheap.

    4. Re:About face! by gstrickler · · Score: 1

      Unstable overrides cheap every time. I'll take stable and fast for $200, Alex.

      --
      make imaginary.friends COUNT=100 VISIBLE=false
    5. Re:About face! by gstrickler · · Score: 1

      Like I said, it's amazing how fast public disclosure can get bugs fixed. Even ones that have been known for 10 years.

      --
      make imaginary.friends COUNT=100 VISIBLE=false
    6. Re:About face! by MightyMartian · · Score: 1

      Or get your ass sued for daring to reveal long-standing bugs that the assholes that maintain it have consistently refused to fix.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    7. Re:About face! by scdeimos · · Score: 1

      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.

    8. Re:About face! by DrXym · · Score: 1

      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.

    9. Re:About face! by petermgreen · · Score: 3, 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).

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    10. Re:About face! by petermgreen · · Score: 1

      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.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    11. Re:About face! by lgw · · Score: 2

      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.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    12. Re:About face! by gstrickler · · Score: 1

      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.

      --
      make imaginary.friends COUNT=100 VISIBLE=false
  2. Bullshit! by Anonymous Coward · · 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.

    1. Re:Bullshit! by Anonymous Coward · · Score: 0

      Yes! HTML Variables for the win!

    2. Re:Bullshit! by Citizen+of+Earth · · Score: 1, Funny

      Java is the fastest programming language ever invented

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

    3. Re:Bullshit! by Anonymous Coward · · 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.

    4. Re:Bullshit! by Anonymous Coward · · 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?

    5. Re:Bullshit! by Anonymous Coward · · Score: 0

      You don't program HTML, artard!

    6. Re:Bullshit! by the+Atomic+Rabbit · · Score: 4, Funny

      There is no way this floating point thing is real.

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

    7. Re:Bullshit! by CharredMetal · · Score: 1

      DOS is classified as a security issue.

    8. Re:Bullshit! by Anonymous Coward · · Score: 0

      What you wanted to say:

      The very simple demonstration of the effect of an inconsistency of floating point number handling locks up the java thread executing the example code.

      Unless somebody looks very closely, there is no reason to believe that other algorithms where somebody intentionally injects numbers triggering inconsistencies are safe against tempering in a more substential way.

      the assertion that a=somethinglikeidentity(b) results in a-b=0 may be important elsewhere.

    9. Re:Bullshit! by Anonymous Coward · · Score: 0

      You forgot how awesome its graphics processing abilities are. For instance, its graphics libraries only use unsigned byte and short data formats for processing grayscale images... And the fucking language has no unsigned types.

    10. Re:Bullshit! by Anonymous Coward · · Score: 0

      I find it sad that you're not just being funny, but channeling that retard 'coder' we've all seen - sadly he exists. :(

    11. Re:Bullshit! by Anonymous Coward · · Score: 0

      sarcasm is your thing...

    12. Re:Bullshit! by Anonymous Coward · · Score: 0

      I thought this article was "Java Floating Point Bug Can Lock Up Sewers", so I clicked on it. I'm gratified to see that there is at least some bullshit here.

    13. Re:Bullshit! by prionic6 · · Score: 2

      Not only is it real, it is rational!

    14. Re:Bullshit! by maxwell+demon · · Score: 1, Funny

      Java is the fastest programming language ever invented

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

      No, video codecs are implemented in Flash because Java always makes those ugly coffee blotches on the videos.

      --
      The Tao of math: The numbers you can count are not the real numbers.
    15. Re:Bullshit! by dkf · · Score: 1

      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.

      --
      "Little does he know, but there is no 'I' in 'Idiot'!"
    16. Re:Bullshit! by AmiMoJo · · Score: 1

      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.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    17. Re:Bullshit! by arth1 · · Score: 1

      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.

    18. Re:Bullshit! by snookiex · · Score: 1

      HTML programmer

      That's the actual joke

      --
      Open Source Network Inventory for the masses! Kuwaiba
    19. Re:Bullshit! by Anonymous Coward · · Score: 0

      If you can target it at specific components, it can be a security bug.

    20. Re:Bullshit! by Anonymous Coward · · Score: 0

      I have been a HTML programmer for many years

      <bdbdbdbdt/>what?

    21. Re:Bullshit! by Anonymous Coward · · Score: 0

      Obvious troll is obvious.

    22. Re:Bullshit! by bluefoxlucid · · Score: 1

      I take Computer Science III, I know what I'm talking about.

      Fixed that for you Mike.

    23. Re:Bullshit! by rreyelts · · Score: 1

      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.

    24. Re:Bullshit! by omfgnosis · · Score: 1

      So is Windows, but they keep selling it anyway.

    25. Re:Bullshit! by Anonymous Coward · · Score: 0

      "Obvious ... is obvious" ... is old and tired. Come up with something new and original.

    26. Re:Bullshit! by lgw · · Score: 1

      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 class of attacks, DoS attacks matter.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    27. Re:Bullshit! by lgw · · Score: 2

      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.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    28. Re:Bullshit! by rreyelts · · Score: 1

      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.

    29. Re:Bullshit! by lgw · · Score: 1

      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.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    30. Re:Bullshit! by Anonymous Coward · · Score: 0

      I would agree with you if your email was dated 1965. Back there it would have been better than Cobol or Fortran.

      FYI, Java was created for the "programmers" who didn't get C++...

      About the future...hmmmm...(.NET)

      HTML is from the past...please consider moving to aspx.

    31. Re:Bullshit! by Anonymous Coward · · Score: 0

      I think he's insinuating that floating points are just fixed points on LSD.

    32. Re:Bullshit! by Anonymous Coward · · Score: 0

      Why do we still think these jokes are funny? Hahah, sarcasm about the JVM! These jokes were only moderately funny 5 years ago. (Not saying you're wrong just saying it's not funny anymore b/c it's OLD)

  3. Unless... by MrEricSir · · Score: 2

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

    --
    There's no -1 for "I don't get it."
    1. Re:Unless... by gstrickler · · Score: 3, Insightful

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

      --
      make imaginary.friends COUNT=100 VISIBLE=false
    2. Re:Unless... by haruchai · · Score: 1

      damn, i ran out of mod points yesterday. +3 Insightful to you, +5 Funny

      --
      Pain is merely failure leaving the body
    3. Re:Unless... by gstrickler · · Score: 0

      Great sig.

      --
      make imaginary.friends COUNT=100 VISIBLE=false
    4. Re:Unless... by Anonymous Coward · · Score: 0

      Adobe even has a way to combine both. They inherited Macromedia's JRun.

    5. Re:Unless... by omfgnosis · · Score: 1

      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.

    6. Re:Unless... by gstrickler · · Score: 1

      Someone wasted a mod point to mod down my compliment? Try reading the moderator guidelines.

      --
      make imaginary.friends COUNT=100 VISIBLE=false
  4. And how soon was the PHP bug fixed again ? by unity100 · · Score: 0

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

    1. Re:And how soon was the PHP bug fixed again ? by Anonymous Coward · · 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

    2. Re:And how soon was the PHP bug fixed again ? by Eunuchswear · · Score: 1

      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?

      --
      Watch this Heartland Institute video
    3. Re:And how soon was the PHP bug fixed again ? by UnknowingFool · · Score: 1

      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.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    4. Re:And how soon was the PHP bug fixed again ? by Anarke_Incarnate · · Score: 1

      Yes. The thing that distracted them is the lack of "Have." Luckily, they substituted "Of." :P

  5. So much for Open Source by bogaboga · · Score: 0, Flamebait

    Sun/Oracle has known about the bug for something like 10 years.

    Those who touted Open Source will not like this piece of news. But they will always find a scapegoat. So much for Open Source!

    1. Re:So much for Open Source by Beelzebud · · Score: 1

      Yes because this will surely bring down the world of Open Source for good!

    2. Re:So much for Open Source by Anonymous Coward · · Score: 0

      Java was not open source for most of that 10 years. This bug and other have been fixed since it became open source. Hmmmm. So much for open source!

  6. I've solved it! by MarkRose · · Score: 0

    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?

    --
    Be relentless!
  7. An infinite Java loop? Sounds interesting... by ibsteve2u · · Score: 1

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

    --
    Orwell: "In a Time of Universal Deceit, telling the Truth is a Revolutionary Act"
  8. Don't you see? It's a feature! by todd.gardner · · Score: 1

    Write once, exploit anywhere!

  9. Java, don't need it, don't want it! by Anonymous Coward · · 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

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

    1. Re:Java, don't need it, don't want it! by FutureDomain · · Score: 0

      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.

      --
      Hydraulic pizza oven!! Guided missile! Herring sandwich! Styrofoam! Jayne Mansfield! Aluminum siding! Borax!
    2. Re:Java, don't need it, don't want it! by Lennie · · Score: 1

      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.

      --
      New things are always on the horizon
    3. Re:Java, don't need it, don't want it! by Anonymous Coward · · Score: 0

      Minecraft needs Java :(

  10. Shocked! Shocked! by curmudgeon99 · · Score: 4, Funny

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

  11. So what if they've known about it for 10 years? by Tony+Isaac · · 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 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.

    1. Re:So what if they've known about it for 10 years? by Anonymous Coward · · Score: 0

      It also sounds like the 10 year old bug didn't have a repro. It was only after someone found the magic number the caused it that it was able to be fixed.

    2. Re:So what if they've known about it for 10 years? by scdeimos · · Score: 2

      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.

    3. Re:So what if they've known about it for 10 years? by ADRA · · Score: 2

      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.

      --
      Bye!
    4. Re:So what if they've known about it for 10 years? by Anonymous Coward · · Score: 1

      What the fuck are you talking about, Java powers the majority of major internet sites. It has done so for a long, long time.

    5. Re:So what if they've known about it for 10 years? by Anonymous Coward · · Score: 1

      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

    6. Re:So what if they've known about it for 10 years? by tomhudson · · Score: 1
      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.

    7. Re:So what if they've known about it for 10 years? by RocketRabbit · · Score: 1

      Actually it's PHP that powers most internet sites, but thanks for playing.

    8. Re:So what if they've known about it for 10 years? by Anonymous Coward · · Score: 0

      Google, Youtube, Yahoo, Wikipedia, Twitter, Blogger

      Uh oh, that's a majority you dolt.

    9. Re:So what if they've known about it for 10 years? by Anonymous Coward · · Score: 0

      Erm, php powers the most porn sites.
      Java does all the important stuff

    10. Re:So what if they've known about it for 10 years? by prionic6 · · Score: 1

      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.

    11. Re:So what if they've known about it for 10 years? by kaffiene · · Score: 1

      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.

    12. Re:So what if they've known about it for 10 years? by kaffiene · · Score: 1

      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.

    13. Re:So what if they've known about it for 10 years? by kaffiene · · Score: 1

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

    14. Re:So what if they've known about it for 10 years? by kaffiene · · Score: 0

      You dumb fuck, over half of those ARE Java powered... WTF happened to /. having posters who knew something about tech??

      Now that you've proved the initial assertion you were trying to argue against (dickhead), answer the contrary question: how many PHP sites in that top 10?

    15. Re:So what if they've known about it for 10 years? by MemoryDragon · · Score: 1

      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.

    16. Re:So what if they've known about it for 10 years? by snookiex · · Score: 1

      Priority is often calculated from two variables: impact and likelihood. I guess they weren't so wrong about the latter. In any case they screwed it badly.

      --
      Open Source Network Inventory for the masses! Kuwaiba
    17. Re:So what if they've known about it for 10 years? by tomhudson · · Score: 1
      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.

    18. Re:So what if they've known about it for 10 years? by Compaqt · · Score: 2

      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.

      --
      I'm not a lawyer, but I play one on the Internet. Blog
    19. Re:So what if they've known about it for 10 years? by Desler · · Score: 0

      Awwww, is a Java weenie mad because all their supposed claims about the security of Java are lately being shown to be false?

    20. Re:So what if they've known about it for 10 years? by s122604 · · Score: 1

      Oh, who are you, coming in here with facts and reason, you're disturbing a good anti-java derp carnival

    21. Re:So what if they've known about it for 10 years? by s122604 · · Score: 1

      Right

      because its impossible to do anything this dangerous or insecure in C++

    22. Re:So what if they've known about it for 10 years? by Anonymous Coward · · Score: 0

      Is PHP everywhere on high-profile important sites?

    23. Re:So what if they've known about it for 10 years? by dougmc · · Score: 1

      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.

    24. Re:So what if they've known about it for 10 years? by tomhudson · · Score: 1
      Pretty much. How often is wikipedia the first or second result - and it runs on php.

      http://www.facebook.com/login.php, 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, digg, etc. Even the white house's site http://whitehouse.gov/ runs php.

      Not too many large sites use Java. Mostly corporate e-payment systems.

    25. Re:So what if they've known about it for 10 years? by Lisandro · · Score: 1

      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.

    26. Re:So what if they've known about it for 10 years? by Lennie · · Score: 1

      So which large sites use Java to power their site ?

      --
      New things are always on the horizon
    27. Re:So what if they've known about it for 10 years? by Anonymous Coward · · Score: 0

      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.

      If you fixed the window so it wouldn't be vulnerable to the certain frequency of vibration, they'd probably have to start carrying bricks again.

    28. Re:So what if they've known about it for 10 years? by lgw · · Score: 2

      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.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    29. Re:So what if they've known about it for 10 years? by Desler · · Score: 1

      because its impossible to do anything this dangerous or insecure in C++

      The point of this irrelevant statement is what? Do C++ programmers en masse claim that you can't do dangerous things in C++? On the other hand, Java weenies continually beat drum about how Java is safer, etc yet there have been how many high profile exploits against the JVM just in the last few months?

    30. Re:So what if they've known about it for 10 years? by afabbro · · Score: 1

      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 the inverse. If you measure by number of financial transactions (banks, etc.) where web users hit Java vs. PHP, it's a divide by zero error.

      --
      Advice: on VPS providers
    31. Re:So what if they've known about it for 10 years? by icebraining · · Score: 1

      Well, there's Wikipedia, Facebook (converted to C++ with HipHop, but still) and Flickr.

    32. Re:So what if they've known about it for 10 years? by tomhudson · · Score: 1
      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.

    33. Re:So what if they've known about it for 10 years? by dougmc · · Score: 1

      So which large sites use Java to power their site ?

      Ebay
      Amazon uses it, among other things
      google uses it, among other things (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, however.)

      php is used for more smaller sites it seems -- if you install your own blogging or forum package, odds are good it's php. java seems more popular with larger commercial sites. Certainly, these aren't hard and fast rules -- Facebook uses php very heavily (but it has some java in there too) and more than a few personal sites use java.

      Which is used for more "major internet sites"? Got me -- but first you'd have to define that term. I would fully expect that php is used in far more sites total than java, however.

    34. Re:So what if they've known about it for 10 years? by dougmc · · Score: 1

      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.

    35. Re:So what if they've known about it for 10 years? by Lennie · · Score: 1

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

      --
      New things are always on the horizon
  12. Re:An infinite Java loop? Sounds interesting... by PopeRatzo · · Score: 2

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

    --
    You are welcome on my lawn.
  13. Hex. by zooblethorpe · · Score: 1

    The supercomputer Hex. Only at the Unseen University. "Anthill Inside"!

    --
    "What in the name of Fats Waller is that?"
    "A four-foot prune."
  14. Encountered this a couple years ago by prehistoricman5 · · Score: 2, Interesting

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

    --
    Fuck Beta
  15. Do NOT try this by c0lo · · Score: 3, Funny
    Try this:

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

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

    --
    Questions raise, answers kill. Raise questions to stay alive.
    1. Re:Do NOT try this by Anonymous Coward · · Score: 0

      Neither work...
      The program 'curl' is currently not installed. To run 'curl' please ask your administrator to install the package 'curl'

      I think you missed the part about not trying this...

    2. Re:Do NOT try this by Anonymous Coward · · Score: 0

      Windows cannot find 'curl''. Make sure you have typed the name correctly, and then try again.

      :(

    3. Re:Do NOT try this by dougmc · · Score: 1

      Isn't slashcode written in perl rather than java?

      Oh ... I see what you did there!

    4. Re:Do NOT try this by snookiex · · Score: 1

      +1 Funny. But apparently you can install it

      --
      Open Source Network Inventory for the masses! Kuwaiba
    5. Re:Do NOT try this by Lennie · · Score: 1

      Actually, it looks like they use Varnish as a kind of loadbalancer.

      --
      New things are always on the horizon
  16. Re:An infinite Java loop? Sounds interesting... by ibsteve2u · · Score: 1

    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.

    --
    Orwell: "In a Time of Universal Deceit, telling the Truth is a Revolutionary Act"
  17. Fixed available by Wookie+Monster · · Score: 5, Informative

    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

    1. Re:Fixed available by Carewolf · · Score: 1

      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.

    2. Re:Fixed available by Anonymous Coward · · Score: 0

      Where does that "10 year old bug" info comes from? Linked-to patches are from one year ago. Or did the submitter do off-by-an-order-of-magnitude error with his time calculations?

  18. Cool! by Anonymous Coward · · Score: 0

    From now on, I'm totally inputting 2.2250738585072011e-308 on every text field that asks for a number.

    1. Re:Cool! by Anonymous Coward · · Score: 2, Funny

      Thats the combination to my luggage!

    2. Re:Cool! by MemoryDragon · · Score: 1

      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.

    3. Re:Cool! by CynicTheHedgehog · · Score: 1

      NumberConverter (which uses DecimalFormat.parse) will produce either a Long or a Double (if the value will not fit into a Long). (I was mistaken in an earlier post where I stated that it produces a BigDecimal. You can specify BigDecimal parsing using DecimalFormat.setParseBigDecimal, but this is not the default.) I looked at the source code for DigitFormat on grepcode and it looks like Sun's DecimalFormat implementation parses all the digits in the input string as a DigitList object, which then reconstructs the string before calling Double.parseDouble. The result is that "2.2250738585072012e-308" becomes "2.2250738585072014" before being passed into Double.parseDouble. So if you're using DecimalFormat or, for example, (which is backed by javax.faces.convert.NumberConverter, which uses DecimalFormat) then you should be safe.

  19. Fails to Work on Android by virtigex · · Score: 1

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

    1. Re:Fails to Work on Android by Anonymous Coward · · Score: 0

      Android uses DVM, not JVM.

    2. Re:Fails to Work on Android by MemoryDragon · · Score: 1

      Guess they simply used the Harmony Code for this stuff and Harmony does not have the bug in.

    3. Re:Fails to Work on Android by TheThiefMaster · · Score: 1

      If it's the same problem PHP had, then it requires an x86 FPU.

    4. Re:Fails to Work on Android by cnettel · · Score: 1

      The bug is in Java code, not underlying JVM code. Java goes to great lengths to maintain IEEE compliance, which means that it truncates to 64-bit precision everywhere.

    5. Re:Fails to Work on Android by atomice · · 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

    6. Re:Fails to Work on Android by Anonymous Coward · · Score: 0

      Doesn't it only do that with strictfp?

    7. Re:Fails to Work on Android by Lisandro · · Score: 1

      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.

    8. Re:Fails to Work on Android by rekrowyalp · · Score: 1

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

      LOL, you should let Google's lawyers know, they could use this as a defence against Oracle

    9. Re:Fails to Work on Android by lskovlund · · Score: 1

      IEEE compliance doesn't mean what you think it means. Not sure whether Java has changed in this regard since 1998, but it definitely was wrong then

  20. Re:An infinite Java loop? Sounds interesting... by antifoidulus · · Score: 1

    it's made of people?!

  21. Mod parent up, please by Anonymous Coward · · Score: 0

    Mod parent up, please

  22. It is not the JVM .... by Chrisq · · Score: 5, Insightful

    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!

    1. Re:It is not the JVM .... by Anonymous Coward · · Score: 0

      yeah, but on a note, the programming example only "printing" an instantiated double hanging compiler or the vm depending where the data comes from is still dangerous, since its a non-transparent bug (you dont include FloatingDecimal.java explicitly).
      and as programmer converting my double by a print/log function is still part of the fp arithmetic in a certain way or at least very close to it.

      so the bug is in the language implementation.

    2. Re:It is not the JVM .... by Anonymous Coward · · Score: 0

      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!

      And the other part of the summary that is just plain stupid:

      "but application code will still be vulnerable to user input."

      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. Seriously.
      I'm not defending them on this, but this is a fairly minor bug and it's been known for a decade so anybody calling themselves a serious Java programmer already codes around the problem by simply NOT passing those types of strings to the bugged functions. If you're a GOOD Java programmer, you've already overloaded the function and implemented your own bug-free code.

    3. Re:It is not the JVM .... by Chrisq · · Score: 1

      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 says that only three digits after the decimal should be sent.

    4. Re:It is not the JVM .... by CynicTheHedgehog · · Score: 3, 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.)

    5. Re:It is not the JVM .... by meloneg · · Score: 1

      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.

    6. Re:It is not the JVM .... by CynicTheHedgehog · · Score: 1

      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 affected, as the following code results in infinite loops/freezes:

      package foo;

      public class Foo {
      public static void main(String... args) {
      Double.parseDouble("2.2250738585072012e-308");
      }
      }

      So either you have to write code to explicitly parse headers as floats/doubles, or there's some bug in some legacy framework(s).

      Either way, JSF has been around since 2004, and recent demand for AJAX, SOAP, social network integration, and other modern features would seem to drive newer technologies. So there are probably a significant number of applications affected, but they are probably still in the minority.

    7. Re:It is not the JVM .... by lamber45 · · Score: 1

      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() 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 some apps that are using "double" for large integers, or fixed-point quantities; but the regular expression for a general floating-point number is already pretty hairy. Can you give a regular expression that filters out the strings, and only the strings, that lead to this bug?

    8. Re:It is not the JVM .... by Chrisq · · Score: 1

      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 are well conditioned and don't accumulate are well understood by people who have complex computational needs.

      Your assertion that you can "just use big decimal" is like someone who put a shed together telling an architect that you can ensure that a structure is strong enough by bunging in a few extra nails.

    9. Re:It is not the JVM .... by CynicTheHedgehog · · Score: 1

      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 is a good post on the problem with relevant examples.

      Stated another way, if you are collecting a floating point value as input, chances are it has to deal with GIS coordinates, monetary values, grade point average, or perhaps some scientific value with known precision, in which case BigDecimal would be more appropriate and therefore immune to this particular problem.

    10. Re:It is not the JVM .... by CynicTheHedgehog · · Score: 1

      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") is not. The resulting Double value for the latter is actually 2.2250738585072014.

    11. Re:It is not the JVM .... by Anonymous Coward · · Score: 0

      Exactly. Moreover the HTTP specs are pretty clear on this. You should parse at most 3 digits after the decimal in that HTTP header.

      So Tomcat is, anyway, not respecting the spec.

      Where Double.parseDouble not broken, 2.2250738585072012e-308 is very different from 2.225.

    12. Re:It is not the JVM .... by Anonymous Coward · · Score: 0

      Precision is rarely critical in the real world, although I admire your integrity. In work that I do, estimating, very intensive, rigorous estimating, is the name of the game. This is known by some as engineering, and I find it hard to lump engineering under a "small subset" use case umbrella.

      It sounds like your particular use case may allow you this opportunity, but please don't assume that that shoe fits everyone.

  23. Re:An infinite Java loop? Sounds interesting... by gstrickler · · Score: 1

    How slow is an infinite loop in Java? Now much memory does it take to execute?

    --
    make imaginary.friends COUNT=100 VISIBLE=false
  24. Another infinite loop (in C#, Java, PHP, C/C++...) by Anonymous Coward · · Score: 0

    Another floating point issue (that hits at a much lower value) ALSO creates infinite loops and has been explained one year ago (without anyone Slashdoting it) while it harms C#, Java or PHP as well as C/C++:

    http://gwan.ch/#infiniteloop

    Know your tools...

  25. deja vu by Anonymous Coward · · Score: 0

    Our GUI mostly does NOT use floating point. When we switched to 1.4, we immediately run into a JVM crash - compiled code improperly handled coprocessor stack.
    It is a shame something like this passes testing.

  26. Tomcat is actually at fault by Anonymous Coward · · Score: 0

    Tomcat is at fault.

    The HTTP specs specifies that you should parse at most three digits in the HTTP header "Accepted-language". Tomcat is faulty here for using floating-point to store fixed-precision decimal numbers (hint: Q: how do you store accurately x.yyy in a floating-point number? A: you don't).

    So, sure, there's a nasty gigantic Java bug in there. But there's also a case of people using floating-point numbers where they really shouldn't.

    2.2250738585072012e-308

    should be parsed as "2.225" according to the HTTP specs for the "Accepted-language" HTT header.

    It's not just "Java the API" that is a fault here: it's "Java the ecosystem".

    Fundamentally, the real issue is about people using floating-point numbers without an epsilon (i.e. for something else than scientific computation). It's like people using floating-point number to store monetary amounts.

    It's sad to see such a gross mistake made in Tomcat. This is really noobie 101 stuff.

  27. ;-) Who would ever do that anyway..... by Anonymous Coward · · Score: 0

    That is why no Java programmers would ever use "Double.parseDouble"..

    In my company they would get fired :-) Even before this bug was known.. It is hard to find a reason for such code anywhere.. Much faster and usable classes out there that would be used in server applications..

  28. Java Floating Point Bug Can Lock Up Server by Anonymous Coward · · Score: 0

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