2012/1/21 David Jorm <dj...@redhat.com>: > Hi All > > I am working on resolving the CVE-2012-0022 DoS in JBoss Web, and I wanted to > confirm some details if anyone can help. 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 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. With this > limit in place, I am unable to reproduce CVE-2012-0022 by passing in a very > large number of parameters. 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?
1. The old code has a number of inefficiencies. We also found that it stumbles upon a bug in Java 6 JRE that makes overall performance to be dependent on (number of parameters * post size). The bug is in implementation of java.lang.StringCoding#decode(Charset, byte[], int, int). Looking at sources that come with JDK it is still present in 6u30, but is fixed in 7u2. The new code fixes inefficiencies and workarounds the bug, so performance should be (number of parameters + post size). 2. Limiting the number of parameters has an inherent caveat: the extra parameters are rejected silently. So in theory it may cause data loss in applications. The cause is that Servlet API does not have proper way to indicate that there was a problem with parameter parsing. The fix for (CVE-2011-4858 + CVE-2012-0022) that added parameter count limit, and subsequent commits, also added a new feature: the problems in parameter parsing are now reported through a custom attribute in a Request and can be dealt with in an application. A new standard filter was added that uses this new feature: FailedRequestFilter. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org