-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David,
On 1/21/12 3:02 AM, David Jorm wrote: > Based on reading the advisory and Tomcat patch code, it seems to me > that the issue is simply slow processing when a very large number > of parameters is received with a request. The parameter names must have colliding hash code values in order to exercise this particular vulnerability. Otherwise, large numbers of request parameters is merely a potential memory exhaustion vulnerability (which is a different issue). > The JBoss Web patch we implemented for CVE-2011-4858 (hash DoS) > limits the number of parameters that can be passed with a request > to 512 by default. Limiting the number of request parameters is one mitigating technique. Tomcat uses 10000 as the default limit which seems reasonable for most users and, of course, can be raised or lowered if necessary. I recently did some testing that indicated that 10000 colliding string values didn't represent much of a CPU load and was somewhere near the inflection point where using a TreeMap instead of a HashMap would start becoming a reasonable trade-off performance-wise (TreeMap is a lot slower compared to a HashMap for smaller population sizes but does not suffer from the hash collision vulnerability). > With this limit in place, I am unable to reproduce CVE-2012-0022 > by passing in a very large number of parameters. Were you able to reproduce CVE-2012-0022 /before/ adding this limit? It's always good to make sure you've actually changed something. > I wanted to check whether handling a very large number of > parameters is all that is required to resolve CVE-2012-0022, or > whether there is something more to it that I have missed? I think you've got in general. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8cgjgACgkQ9CaO5/Lv0PBRqACgqzs6wgL0luk717XIOYaawWjk lEgAnjhSCX0jTiORUiEZDzw4oOdvBeuX =I+pd -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
