1 Reply Latest reply: May 16, 2012 10:48 PM by Stephen Coy RSS

updating Jbossweb.jars to fix hash collision

Manjesh h Newbie

Hi ,

 

I have a product built on  Jboss 4.23.000.  We found from an internal auditing team that this version of Jboss’s web-container has a known vulnerability called  “Hash Collision” .

The workaround available by setting a configuration parameter Dorg.apache.tomcat.util.http.Parameters.MAX_COUNT is not application to Jboss 4.23.00 version .

 

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4858

 

 

I have seen that Jboss 7.x has a workaround fix for this issue.

 

 

  1. Is it possible to upgrade only the web-container part of Jboss 423  to  Jboss 7.x web container so that the vulnerability get addressed?

If this is recommended,  along with jbossweb.jar which are all other jars needs to be  copied to Jboss 4.23.00 ? because I notice in Jboss’s7 web module  there are more number of jars this time.

  1. I have an alternate option to see the source code of Jboss 7.x ‘s  jbosspiweb.jar  to check how does it handles the workaround (setting .apache.tomcat.util.http.Parameters.MAX_COUNT)..then

Change the same code in Jboss 423’s jbossweb.src and rebuild locally to  address this security issue.

 

I know by doing this way solves only one security issue but not the rest fixed by Jboss 7.x

 

Please suggest me which option is better given a constraint that we cannot chose to migrate to Jboss 7.x at this point of time.

 

-thanks

Manjesh

  • 1. Re: updating Jbossweb.jars to fix hash collision
    Stephen Coy Master

    Manjesh h wrote:

     

    ...

    1. Is it possible to upgrade only the web-container part of Jboss 423  to  Jboss 7.x web container so that the vulnerability get addressed?

    If this is recommended,  along with jbossweb.jar which are all other jars needs to be  copied to Jboss 4.23.00 ? because I notice in Jboss’s7 web module  there are more number of jars this time.

    ...

    I think this is unlikely to work

     

    Manjesh h also wrote:

     

    1. I have an alternate option to see the source code of Jboss 7.x ‘s  jbosspiweb.jar  to check how does it handles the workaround (setting .apache.tomcat.util.http.Parameters.MAX_COUNT)..then

    Change the same code in Jboss 423’s jbossweb.src and rebuild locally to  address this security issue.

    This is what I would be doing...