7

Most Java JVMs are subject to a very severe Denial of Service (all Oracle/Sun JVMs pre 1.6.0_24 [that ain't out yet at the time of this writing] and that didn't get the HotFix that came out yesterday, for example).

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

The following:

curl -H 'Accept-Language: en-us;q=2.2250738585072012e-308' http://example.org

crashes a lot of the Tomcat webservers on the planet.

My question is simple: who's at fault?

Apparently getLocale() calls the (very badly) bugged Double.parseDouble(...) and you can then trivially perform a Denial of Service on Tomcat.

Is the bugged implementation of Double.parseDouble(...) really at fault?

To me it looks like the real issue is that the HTTP specs are using floating-point numbers for something that really doesn't look very much like scientific computation to me. Using floating-point number for such a thing seems more than weird: it is easy to prove that implementation in different language shall give different results.

So who's at fault?

Java's terribly lame (bug was known since 10 years) implementation of Double.parseDouble(...)?

The HTTP specs? (remember that PHP suffered the exact same bug).

I can understand you blame the language if it happens with one language... But when two remote Denial of Service attacks happens to two different languages due to the fact that the HTTP specs dictate parsing of floating-point number for something that is not a scientific computation should ring a bell.

Floating-point numbers should only ever be used for scientific computations. If you don't have floating-point numbers and no epsilon, you're doing it wrong.

Yi Jiang
  • 49,435
  • 16
  • 136
  • 136
SyntaxT3rr0r
  • 27,745
  • 21
  • 87
  • 120
  • Btw... This is the worst denial of service bug that ever hit Java in its lifetime. I hope we'll never see worse because it is already very, very, ugly. – SyntaxT3rr0r Feb 11 '11 at 00:05
  • Seems more like a complaint than a programming question, but I'd say its completely Java's fault. Voting to close as subject and argumentative, but until I make an argument :) – President James K. Polk Feb 11 '11 at 00:06
  • 5
    On the other hand, that's probably the coolest tag on Stack Overflow. – sdleihssirhc Feb 11 '11 at 00:06
  • 2
    Much can be said about Oracle and Sun, but Sun sat on this bug apparently for 10 years. Oracle ships an emergency update. – Thorbjørn Ravn Andersen Feb 11 '11 at 00:09
  • @sdleihssirhc: yup, thought that too... I created this tag and it definitely does rock. My question is real that said. I'd like to understand what made such a mess possible. I'm nearly convinced that a **lot** of bad things can be said about putting decimal value in HTTP header specs... – SyntaxT3rr0r Feb 11 '11 at 00:14
  • To all: don't vote to close the question on SO that has the coolest tag ever ;) – SyntaxT3rr0r Feb 11 '11 at 00:15
  • @irreputable: but PHP got bitten too. If we look a bit further into this, are you really *sure* the HTTP specs look great and smart and all? To me it looks like a case of people-who-wrote-the-HTTP-spec-didn't-read the seminal *"What every computer scientist should know about floating point numbers"* – SyntaxT3rr0r Feb 11 '11 at 00:16
  • 1
    @SyntaxT3rr0r It's Java's fault. Floating-point numbers are just one of many reasonably complex data structures that modern programming relies on, and the point is simply that Java didn't have a good implementation for it. You can't ask people to stop using data structures because there are bad implementations for them, especially when there are a myriad of good ones. – zneak Feb 11 '11 at 00:26
  • There are different planes of defects. Blowing up on number parsing is inexcusable, we cannot look past it until it's fixed. – irreputable Feb 11 '11 at 00:33
  • Gotta love of people vote to close this even though it's a perfectly valid question which can be answered using logic and facts. This is why SO shall never "win". You cannot silence blogs, forums, twitter, etc. The word is out. That question shall be answered, whether you like it or not. – NoozNooz42 Feb 11 '11 at 00:35
  • Btw +5 upvote and two favorites and probably one of the most interesting thing many Java programmers read today on SO... But, yup, SO is soooo flawed. Give people a tiny bit of "power", all this... To me it's definitely the best thing I read today: thanks to this I discovered lots of amazing discussion, much better than SO. – NoozNooz42 Feb 11 '11 at 00:35
  • 1
    I find this to the point a perfectly valid question as well, however I do agree with the closers that there are a bit too much argumentative phrases in the question. Try to lower the accusing tone in the question body and make it neutral. – BalusC Feb 11 '11 at 00:37
  • 3
    @NoozNooz42: SO has never tried to compete with blogs, forums or twitter. It serves a completely different purpose. The notion of SO "winning" is idiotic and meaningless. – John Bartholomew Feb 11 '11 at 00:43
  • 1
    @NoozNooz42: No one is saying it shouldn't be answered. Just not here. Feel free to post whatever you want on your blog. – Bill the Lizard Feb 11 '11 at 01:02

3 Answers3

6

Actually, rfc 2616 (the HTTP/1.1 spec) says:

HTTP/1.1 applications MUST NOT generate more than three digits after the decimal point. User configuration of these values SHOULD also be limited in this fashion.

qvalue    = ( "0" [ "." 0*3DIGIT ] )
          | ( "1" [ "." 0*3("0") ] )

"Quality values" is a misnomer, since these values merely represent relative degradation in desired quality.

Note that this limits the number of digits and does not allow an exponent. I'd think any implementation would be perfectly within the spec to disregard input that has more than 3 fractional digits, and completely ignore anything with an exponent value. The fact that Tomcat doesn't do this is not a problem with the HTTP spec.

John Bartholomew
  • 6,428
  • 1
  • 30
  • 39
  • 2
    +1... sending love to you. This means fixed-precision works here and the HTTP specs are clean. Tomcat is at least partly faulty here. – SyntaxT3rr0r Feb 11 '11 at 00:24
  • 2
    There is absolutely no problem for Tomcat to accept wider range of values (all HTTP servers do that, HTTP is a field where you better be liberal in what you accept), and there is absolutely no problem for Tomcat to rely on Double.parseDouble(). – irreputable Feb 11 '11 at 00:36
  • @irreputable: All true. I put the emphasis on the wrong thing. Although I would venture to suggest that the world would be no worse off if implementations of web related technologies weren't so often written with the spec. treated as though it were just some vague guidelines. – John Bartholomew Feb 11 '11 at 01:01
0

It's not either/or. As with many security problems, it's a result of both of them being at fault. If either one had done their job reasonably well, the problem would never have arisen.

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
-2

This is a problem with the number parsing method in the Java runtime library, not Tomcat - it just use said method.

Edit: The reason why q is a fraction is because it allows you to use a value between two existing values, which may be necessary when providing a value after the initial assignments have happened.

Thorbjørn Ravn Andersen
  • 73,784
  • 33
  • 194
  • 347
  • 2
    yes... But Tomcat uses the parsing because the HTTP specs mandates parsing a floating-point number. I agree, Tomcat's probably not at fault. But it doesn't tell if the real guilty party here are the HTTP specs or the (broken) Java implementation of floating-point parsing. – SyntaxT3rr0r Feb 11 '11 at 00:10
  • @Syntax, and the parsing method is located where..? – Thorbjørn Ravn Andersen Feb 11 '11 at 00:17
  • 1
    @Thorbjørn Ravn Andersen: But PHP got bitten too very badly by this. Doesn't it make you think twice? Once again, to me it looks like a case of people-who-wrote-the-HTTP-spec-didn't-read the seminal *"What every computer scientist should know about floating point numbers"*. I **really** don't see the point of mandating the use of floating point numbers in these HTTP headers. – SyntaxT3rr0r Feb 11 '11 at 00:19
  • @Syntax, how can PHP be bitten by an error in the JVM? – Thorbjørn Ravn Andersen Feb 11 '11 at 00:24
  • @Thorbjørn Ravn Andersen: see John Bartholomew's answer regarding the HTTP specs. Of course (silly me) the HTTP specs specifies 3 digits (making hence floating-point numbers totally unnecessary). Tomcat tries to parse this using a floating-point libray, which is silly (fixed-precision using integers is what they where after, because there's no way to represent correctly on floating-point numbers decimal value that can otherwise be stored just fine). Tomcat *is* guilty of not respecting the spec. – SyntaxT3rr0r Feb 11 '11 at 00:26
  • @SyntaxT3rr0r, I still fail to see how PHP can be bitten by a bug in the JVM. – Thorbjørn Ravn Andersen Feb 11 '11 at 07:31