Question

通过哈希表多次冲突拒绝服务（http://www.nruns.com/_downloads/advisory28122011.pdf）

我希望有人知道为什么Netty的QueryStringDecoder不容易受到这种攻击。

来自引用的.pdf

== Java == Java提供了HashMap和Hashtable类，它们使用String.hashCode（）哈希函数。它与DJBX33A非常相似（而不是33，它使用乘法常数31而不是起始值5381，它使用0）。因此它也容易受到等效的子串攻击。散列字符串时，Java还会在散列属性中缓存散列值，但前提是结果不等于零。因此，目标值零对攻击者来说特别有意义，因为它可以防止缓存并强制重新散列。

不同的Web应用程序以不同的方式解析POST数据，但经过测试的（Tomcat，Geronima，Jetty，Glassfish）都将POST表单数据放入Hashtable或HashMap对象中。最大POST大小也因服务器而异，最常见的是2 MB。

Tomcat 6.0.32服务器在大约44分钟的i7 CPU时间内解析2 MB的冲突密钥串，因此大约6 kbit / s的攻击者可以让一个i7核心不断忙碌。如果攻击者有千兆连接，他可以保持大约100.000个i7核心忙。

Answer 1

...是

Netty不受影响，因为我们已经限制了标头大小。有关详细信息，请参见[1]：

[1] https://github.com/netty/netty/issues/141

Answer 2

看起来Trustin已经考虑过了。

commit 521bf83d0f39896f3c87c54bebd1e8c06e86b60b
Author: Trustin Lee <trustin@gmail.com>
Date:   Fri Dec 30 17:58:51 2011 +0900

    Issue #141: hashdos security vulnerability in QueryStringDecoder and possibly other components

    * Limited maximum number of parameters to 1024 by default and made the
    limitation configurable
    * QueryStringDecoder is now able to handle an HTTP POST content

M       codec-http/src/main/java/io/netty/handler/codec/http/QueryStringDecoder.java
M       codec-http/src/test/java/io/netty/handler/codec/http/QueryStringDecoderTest.java

有没有人认为netty易受oCERT-2011-003的影响？

2 个答案: