大多数未修补的Tomcat Web服务器都很脆弱,谁有错？

Question

大多数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.parseDouble(...)错误的实施是否真的有问题？

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

那谁有错呢？

Java非常蹩脚(bug已知10年以来)实现了Double.parseDouble(...)？

HTTP规范？(记住,PHP遇到了完全相同的错误).

我可以理解,如果用一种语言发生,你会责怪语言......但是当两种不同语言发生两次远程拒绝服务攻击时,由于HTTP规范规定解析浮点数而不是某种语言科学计算应响铃.

浮点数应该只用于科学计算.如果你没有浮点数而没有epsilon,那你就错了.

Answer 1

实际上,rfc 2616(HTTP/1.1规范)说:

HTTP/1.1应用程序必须在小数点后不能生成超过三位数.这些值的用户配置也应该以这种方式受到限制.

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

"质量值"是用词不当,因为这些值仅表示所需质量的相对降低.

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

Answer 2

这是Java运行时库中的数字解析方法的问题，而不是Tomcat - 它只是使用上述方法。

编辑： q 是分数的原因是因为它允许您使用两个现有值之间的值，这在初始分配发生后提供值时可能是必要的。