Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Apache Commons FileUpload vulnerabilities in SmartGWT (upgrade to FileUpload v1.3.1)

    My team are using SmartGWT v2.5 (2011-10-18) Power Edition and v3.0 (2012-02-07) Power Edition. My team is is using Firefox ESR v17.0.4.

    It is found that, both of SmartGWT v2.5 & v3.0 are still using commons-fileupload-1.2.1.jar, which is found to have DDOS vulnerability. The vulnerability has been fixed in Commons FileUpload version 1.3.1 that was released on 2014 Feb. 7.

    However, when we try to upgrade to commons-fileupload-1.3.1.jar in SmartGWT v2.5 PowerEdition and v3.0 PowerEdition, we got the following errors:

    [3/20/14 10:30:31:689 HKT] 000000b3 SystemOut O === 2014-03-20 10:30:31,689 [ : 5] INFO RequestContext - URL: '/XXXXXX_MyApp-web/spring/workspace/IDACall', User-Agent: 'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0;
    SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E; InfoPath.3)': MSIE with Accept-Encoding header, ready for compressed JS
    [3/20/14 10:30:31:732 HKT] 000000b3 SystemOut O === 2014-03-20 10:30:31,730 [ : 5] ERROR IDACall - Top-level servlet error:
    java.lang.AbstractMethodError: com.isomorphic.servlet.ISCFileItem.setHeaders(Lorg/apache/commons/fileupload/FileItemHeaders;)V at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:355)
    at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:288)
    at com.isomorphic.servlet.ISCHttpServletRequest.parseRequest(ISCHttpServletRequest.java:217)
    at com.isomorphic.servlet.ISCHttpServletRequest.parseRequest(ISCHttpServletRequest.java:192)
    at com.isomorphic.servlet.ISCHttpServletRequest.getStringParams(ISCHttpServletRequest.java:116)
    at com.isomorphic.servlet.ISCHttpServletRequest.getParameter(ISCHttpServletRequest.java:253)
    at com.isomorphic.rpc.RPCManager.parseRequest(RPCManager.java:1800)
    at com.isomorphic.rpc.RPCManager.<init>(RPCManager.java:286)
    at com.isomorphic.rpc.RPCManager.<init>(RPCManager.java:271)
    at com.isomorphic.servlet.IDACall.processRequest(IDACall.java:116)
    at com.isomorphic.servlet.IDACall.doPost(IDACall.java:73)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
    at com.isomorphic.servlet.BaseServlet.service(BaseServlet.java:152)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)


    After some checking, it is found that there are method signature change from Commons-Fileupload v1.2.1 to v1.3.1 as follow on org.apache.commons.fileupload.FileItemHeaders:

    Commons FileUpload v1.2.1:
    Iterator getHeaders(String name); to
    Commons FileUpload v1.3.1:
    Iterator<String> getHeaders(String name);

    Commons FileUpload v1.2.1:
    Iterator getHeaderNames(); to
    Commons FileUpload v1.3.1:
    Iterator<String> getHeaderNames();

    Would you please provide a patch on this vulnerability for SmartGWT 2.5 Power Edition / 3.0 Power Edition or you can advise us how we can tackle this vulnerability in SmartGWT v2.5 / 3.0 Power Edition? Thank you very much!

    DDOS Vunerability on Commons FileUpload and Tomcat:
    http://www.pcworld.com/article/2097360/denialofservice-vulnerability-puts-apache-tomcat-servers-at-risk.html.

    This vulnerability allows attackers to take down Tomcat web sites and services. A malicious user can craft a malformed HTTP request, with a non-standard Content-Type multipart header that causes Tomcat to enter an infinite loop. Service can be recovered by rebooting server. A sustained attack could lead to prolong service disruption

    --John Law

    #2
    I have been asked to ensure our applications are not vulnerable to this issue.

    I tried to reproduce the vulnerability with Power 3.1 app and could not. I could reproduce with our newer app using 4.0 but that was caused by our own FileUpload and calling an offending function in commons-fileupload ourselves. We worked about the issue by checking to ensure the content-type header was not too large.

    Could you please comment on this issue and let us know if there are plans to update the code to use v1.3 so we don't have to check for this vulnerability ourselves.

    Comment


      #3
      We will most likely update to 1.3.1 as part of 5.0.

      Did you already try updating to 1.3.1? Johnlaw seems to report it's impossible above, but his stack trace disagrees with the methods he says changed in the library.

      Comment


        #4
        Just a quick note here to announce that tomorrow's 5.0d build (2014-04-17) updates the fileupload dependency to 1.3.1.

        Comment


          #5
          Any plan to also update on SmartGWT v2.5, v3.0 and v4.1? My team will not adopt v5.0 in short period of time. Thanks!
          --John Law

          Comment

          Working...
          X