Community
Participate
Working Groups
A variety of programming languages suffer from a denial-of-service (DoS) condition against storage functions of key/value pairs in hash data structures, the condition can be leveraged by exploiting predictable collisions in the underlying hashing algorithms. The issue finds particular exposure in web server applications and/or frameworks. In particular, the lack of sufficient limits for the number of parameters in POST requests in conjunction with the predictable collision properties in the hashing functions of the underlying languages can render web applications vulnerable to the DoS condition. The attacker, using specially crafted HTTP requests, can lead to a 100% of CPU usage which can last up to several hours depending on the targeted application and server performance, the amplification effect is considerable and requires little bandwidth and time on the attacker side.
The approach I suggested (but received no response to) appears to have been adopted by tomcat, which is to limit the number of entries that a request can make in a map of parameters, cookies, fields etc.
Testing with the provided evil keys show the time taken for adding 1000 keys in ms together with the total data size of the keys as: 1000 33 7KB 2000 80 15KB 3000 46 24KB 4000 72 33KB 5000 94 42KB 6000 121 50KB 7000 143 59KB 8000 166 68KB 9000 189 77KB 10000 213 85KB 11000 239 94KB 12000 260 103KB 13000 285 112KB 14000 306 121KB 15000 335 129KB 16000 354 138KB 17000 377 147KB 18000 406 156KB 19000 426 165KB 20000 452 173KB 21000 473 182KB 22000 499 191KB 23000 535 200KB 24000 548 209KB 25000 569 217KB 26000 590 226KB 27000 616 235KB 28000 640 244KB 29000 661 252KB 30000 694 261KB 31000 714 270KB 32000 738 279KB 33000 760 288KB 34000 786 296KB 35000 811 305KB 36000 835 314KB 37000 860 323KB 38000 884 332KB 39000 909 340KB 40000 935 349KB 41000 968 358KB 42000 988 367KB 43000 1009 375KB 44000 1050 384KB 45000 1073 393KB 46000 1097 402KB 47000 1131 411KB 48000 1148 419KB 49000 1180 428KB 50000 1214 437KB This suggests that any fields contained in a HTTP header (query params, cookies, HTTP headers) will not be vulnerable as they are limited to 4-8KB and are while some CPU is used, it is not much less significant than larger numbers of evil keys. However, the default value for make form content size is 200K, and that can contain several seconds worth of key processing in it. A temporary fix for old jetty releases is to reduce this to 10KB or similar. We will implement a feature to limit the number of items in the form, as well as the total size.
I have added ContextHandler.setMaxFormKeys(int keys) to limit the number of parameters (default 1000). The Request java doc now says: The form content that a request can process is limited to protect from Denial of Service attacks. The size in bytes is limited by {@link ContextHandler#getMaxFormContentSize()} or if there is no context then the "org.eclipse.jetty.server.Request.maxFormContentSize" {@link Server} attribute. The number of parameters keys is limited by {@link ContextHandler#getMaxFormKeys()} or if there is no context then the "org.eclipse.jetty.server.Request.maxFormKeys" {@link Server} attribute. Shirley, I thought we had an eclipse page that was the update of http://docs.codehaus.org/display/JETTY/Jetty+Security but I cannot find it. Can you find/create it and update for this issue - thanks
Updated "Jetty Security Reports" to include this issue, and moved to http://wiki.eclipse.org/Jetty/Jetty_Security_Reports. Please review.
(In reply to comment #4) > Updated "Jetty Security Reports" to include this issue, and moved to > http://wiki.eclipse.org/Jetty/Jetty_Security_Reports. Please review. Is it time to remove the "committer-only" flag?
(In reply to comment #5) > (In reply to comment #4) > > Updated "Jetty Security Reports" to include this issue, and moved to > > http://wiki.eclipse.org/Jetty/Jetty_Security_Reports. Please review. > > Is it time to remove the "committer-only" flag? Ping?
opening this issue up
