9

There's an easy way to totally lock a lot of JVM:

class runhang {
public static void main(String[] args) {
  System.out.println("Test:");
  double d = Double.parseDouble("2.2250738585072012e-308");
  System.out.println("Value: " + d);
 }
}

or, to hang the compiler:

class compilehang {
public static void main(String[] args) {
  double d = 2.2250738585072012e-308;
  System.out.println("Value: " + d);
 }
}

as explained here: http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/

My question is very simple: which kind of well-conceived web application do you know that can realistically be affected by this?

In other words: on which kind of webapps could an attacker perform a Denial of Service using that known weakness?

It is bad, it is terribly bad. But besides programmers using floating-point for monetary computation I don't see many Java-backed websites that can be crashed.

I can see toy scientific applets being candidates but besides that...

Here's a threadump of the blocked thread (done using "kill -3" on Linux):

"main" prio=1 tid=0x09ab8a10 nid=0x57e9 runnable [0xbfbde000..0xbfbde728]
        at sun.misc.FDBigInt.mult(FloatingDecimal.java:2617)
        at sun.misc.FloatingDecimal.multPow52(FloatingDecimal.java:158)
        at sun.misc.FloatingDecimal.doubleValue(FloatingDecimal.java:1510)
        at java.lang.Double.parseDouble(Double.java:482)

EDIT

JVMs locked here:

java version "1.5.0_10" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03) Java HotSpot(TM) Server VM (build 1.5.0_10-b03, mixed mode)

java version "1.6.0_17" Java(TM) SE Runtime Environment (build 1.6.0_17-b04) Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

SyntaxT3rr0r
  • 27,745
  • 21
  • 87
  • 120
  • (how do I turn this into a community Wiki?) – SyntaxT3rr0r Feb 09 '11 at 18:40
  • 2
    Seems like anything that naively converts a user-entered string value into a double could be affected. – Mike Daniels Feb 09 '11 at 18:44
  • How is this not a real question? How can someone vote to close this? – SyntaxT3rr0r Feb 09 '11 at 18:48
  • There is no verifiable technically correct answer? It's a variant of 'every answer is equally valid.' (Was not my close vote, just commenting.) – Affe Feb 09 '11 at 18:53
  • virtually any web-application out there that takes user input. but if you have json input, it's too easily exploitable. – bestsss Feb 09 '11 at 18:58
  • Even IDEs which parse the code as you type can be affected by this bug. – Peter Lawrey Feb 09 '11 at 19:13
  • actually now i recall the a bug like 9 years ago which was able to hang javac, which of course looked unimportant since we used jbuilder; the bug is lurking since 1.3 probably. – bestsss Feb 09 '11 at 19:21
  • @bestsss: zomg... Read the other answers. This is **huge**. Actually huger than most people realize. It didn't know it was that bad. – SyntaxT3rr0r Feb 10 '11 at 20:56
  • @SyntaxT3rr0r, it is huge, ofc it is. you can crash practically any java server that's not patched. how could i say it more clearly than that :) I had discussion a few days back w/ a colleague why the big companies can be such a-h0les, need test case, need blah, blah when the off-by-one is so damn visible. Back in the day, there was a race condition (using static variable, not ThreadLocal) in 1.4 for Double.toString(d), and still my head can't grasp why this issue has not been patched along the case. – bestsss Feb 10 '11 at 21:34

5 Answers5

8

Many web servers parse part of the http headers using Double.parse, so we are dealing with infrastructure here (in addition to any problems with applications that run in the container). The comments of the Exploring Binary blog you link to have the following as an example:

GET / HTTP/1.1
Host: myhost
Connection: keep-alive
Accept-Language: en-us;q=2.2250738585072012e-308

If the servlet that the request is going against makes a call to any of the localization APIs (which would then attempt to parse the language header), the above will bring the server down.

So yes, this is a very big problem. The attack surface is quite large, and the consequences quite high.

Kevin Day
  • 16,067
  • 8
  • 44
  • 68
  • 2
    +1. zomg. This is **HUGE**. Huger than most people (especially Java fanbois... Don't get me wrong: I *love* Java) realize. – SyntaxT3rr0r Feb 10 '11 at 20:45
7

Hate to state the obvious, but all application that lets the user submits the string "2.2250738585072011e-308", and calls parse double on can "realistically" be affected.

mikerobi
  • 20,527
  • 5
  • 46
  • 42
  • Don't know if you stating the obvious deserves a +1 for you or a -1 for the question. Anyways I am taking the easy way out. – uncaught_exceptions Feb 09 '11 at 18:49
  • I would also like to add that, this case is very relevant to most of the rest based service. Any application that does not necessarily sanitize the input. ( not that I am saying that all application should sanitize everything). Having said that most application framework do handle this type conversion evil. ( they are smart enough to not to perform type safe operation) – uncaught_exceptions Feb 09 '11 at 18:53
4

All versions of Tomcat have been patched and released to handle the "Accept-Language" condition.

Oracle has released a hot fix which can be found here:

http://www.oracle.com/technetwork/java/javase/fpupdater-tool-readme-305936.html

The hotfix will work for java 1.4, 1.5, and 1.6.

Tim Funk
  • 869
  • 7
  • 11
  • zomg. This ain't even a "CPU" (Critical Patch Update). It's a hotfix. This speaks volume as to how vulnerable most Java webservers are. – SyntaxT3rr0r Feb 10 '11 at 20:55
1

Anything where you let the user enter a floating point number and do a comparison or calculation on it should be suspect. I would say a payment form, loan calculator, and bidding form would be the most common. All it would take is one little calculator utility in your entire application to be able to hang the web server by repeated hits.

JOTN
  • 6,120
  • 2
  • 26
  • 31
0

I understand that this number is only one in a range of numbers that would crash applications but just couldn't resist commenting, check the last 4 digits. 2012, it speaks volumes of the number, the ancient predicted doomsday, and our modern applications are pointing to a crashing threshold unless fixed :-)

PasserBy
  • 1