大多数未修补的Tomcat Web服务器都很脆弱，谁有错？ [英] Most unpatched Tomcat webservers are vulnerable, who's at fault?

问题描述

大多数Java JVM都受到非常严重的拒绝服务（所有Oracle / Sun JVM在1.6.0_24之前[在撰写本文时还没有出现]并且没有得到所发布的HotFix昨天，例如）。

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

以下内容：

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

崩溃了地球上Tomcat网络服务器的很多。

我的问题很简单：谁有错？

显然 getLocale（）调用（非常严重）错误的 Double.parseDouble（...），然后您可以在Tomcat上轻松执行拒绝服务。

的错误实现Double.parseDoub le（...）真的有问题吗？

对我而言，真正的问题似乎是HTTP规范正在使用浮点数对于我来说真的看起来不像科学计算的东西的数字。对这样的事情使用浮点数似乎不仅奇怪：很容易证明用不同语言实现会产生不同的结果。

那么谁有错？ / p>

Java非常蹩脚（自10年以来就知道错误） Double.parseDouble（...）的实现？

HTTP规范？ （记住，PHP遇到了完全相同的错误）。

我能理解你如果用一种语言发生的话会责怪语言......但当两个远程拒绝时服务攻击发生在两种不同的语言中，因为HTTP规范要求解析浮点数，因为不科学计算应响铃。

浮点数应仅用于科学计算。如果你没有浮点数而没有epsilon，那你做错了。

解决方案

实际上，rfc 2616 （HTTP / 1.1规范）说：

HTTP / 1.1应用程序必须在
小数点后生成三位数以上。这些值的用户配置也应该以这种方式限制为
。

  qvalue =（0[。 0 * 3DIGIT]）
 | （1[。0 * 3（0）]）
  

质量值这是一个误称，因为这些价值只代表
所需质量的相对退化。

请注意，这限制了数字，不允许指数。我认为任何实现都将完全符合规范，忽略具有超过3个小数位的输入，并完全忽略具有指数值的任何内容。 Tomcat不这样做的事实不是HTTP规范的问题。

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.

解决方案

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.

这篇关于大多数未修补的Tomcat Web服务器都很脆弱，谁有错？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！