ICEfaces
  1. ICEfaces
  2. ICE-11437

Fix CVE-2016-3092 Specially crafted input can trigger a DoS, if the size of the MIME boundard is close to the size of the buffer in MultipartStream

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.3, EE-3.3.0.GA_P06
    • Fix Version/s: EE-4.3.0.GA, EE-3.3.0.GA_P07
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      Any

      Description

      Sometime ago we fixed another security issue in our Apache Commons FileUpload code, CVE-2014-0050, as per ICE-10023.

      There's another security issue, CVE-2016-3092, similar to the last one we fixed that we haven't fixed in our code. However, it is not clear whether our code has that vulnerability or not. So, we must investigate further and apply the fix if necessary or state why that fix is not necessary.

      http://commons.apache.org/proper/commons-fileupload/changes-report.html

        Issue Links

          Activity

          Arturo Zambrano created issue -
          Arturo Zambrano made changes -
          Field Original Value New Value
          Assignee Arturo Zambrano [ artzambrano ]
          Arturo Zambrano made changes -
          Link This issue depends on ICE-10023 [ ICE-10023 ]
          Ken Fyten made changes -
          Fix Version/s EE-4.3.0.GA [ 13103 ]
          Fix Version/s EE-3.3.0.GA_P07 [ 13118 ]
          Repository Revision Date User Message
          ICEsoft Public SVN Repository #52780 Thu Nov 15 15:26:06 MST 2018 art.zambrano ICE-11437: committed fix for the CVE-2016-3092 vulnerability to our apache commons fileupload codebase
          Files Changed
          Commit graph MODIFY /icefaces4/trunk/icefaces/ace/component/src/org/icefaces/apache/commons/fileupload/MultipartStream.java
          Hide
          Arturo Zambrano added a comment -

          Even though, the date (2014-02-07) indicated in http://commons.apache.org/proper/commons-fileupload/changes-report.html for the fix for CVE-2016-3092 in 1.3.2 is the same as the date indicated for the fix for CVE-2014-0050 in 1.3.1, this is incorrect. The actual date on which the fix for CVE-2016-3092 in 1.3.2 was made is 2016-05-12, as can be seen in the commits log of the Apache Commons FileUpload repository found on these pages:

          So, it's safe to assume that the date being the same for these two fixes was a mistake on the page itself, presumably for simply copy/pasting some markup, which discards the possibility of CVE-2016-3092 being indirectly fixed and not applicable in 1.3.1.

          There can be found multiple statements about CVE-2016-3092 actually affecting 1.3.1, as can be seen in the following pages:

          However, no fix seems to have been applied to the 1.3.1 version, which is the one in our codebase.

          The actual fix is simple enough and consists in making the buffer size bigger if it's not big enough, as can be seen in the following revision log and diff record for this fix, respectively:

          r52780: committed fix for the CVE-2016-3092 vulnerability to our apache commons fileupload codebase (4.3 trunk)
          r52781: committed fix for the CVE-2016-3092 vulnerability to our apache commons fileupload codebase (EE 3.3 maintenance branch)

          Show
          Arturo Zambrano added a comment - Even though, the date (2014-02-07) indicated in http://commons.apache.org/proper/commons-fileupload/changes-report.html for the fix for CVE-2016-3092 in 1.3.2 is the same as the date indicated for the fix for CVE-2014-0050 in 1.3.1, this is incorrect. The actual date on which the fix for CVE-2016-3092 in 1.3.2 was made is 2016-05-12, as can be seen in the commits log of the Apache Commons FileUpload repository found on these pages: http://svn.apache.org/viewvc?view=revision&revision=1743480 http://svn.apache.org/viewvc/commons/proper/fileupload/trunk/src/main/java/org/apache/commons/fileupload/MultipartStream.java?view=log&pathrev=1743480 So, it's safe to assume that the date being the same for these two fixes was a mistake on the page itself, presumably for simply copy/pasting some markup, which discards the possibility of CVE-2016-3092 being indirectly fixed and not applicable in 1.3.1. There can be found multiple statements about CVE-2016-3092 actually affecting 1.3.1, as can be seen in the following pages: https://commons.apache.org/proper/commons-fileupload/security-reports.html https://nvd.nist.gov/vuln/detail/CVE-2016-3092 https://www.cvedetails.com/cve/CVE-2016-3092/ However, no fix seems to have been applied to the 1.3.1 version, which is the one in our codebase. The actual fix is simple enough and consists in making the buffer size bigger if it's not big enough, as can be seen in the following revision log and diff record for this fix, respectively: http://svn.apache.org/viewvc?view=revision&revision=1743480 http://svn.apache.org/viewvc/commons/proper/fileupload/trunk/src/main/java/org/apache/commons/fileupload/MultipartStream.java?r1=1743480&r2=1743479&pathrev=1743480 r52780: committed fix for the CVE-2016-3092 vulnerability to our apache commons fileupload codebase (4.3 trunk) r52781: committed fix for the CVE-2016-3092 vulnerability to our apache commons fileupload codebase (EE 3.3 maintenance branch)
          Arturo Zambrano made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Ken Fyten made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              Arturo Zambrano
              Reporter:
              Arturo Zambrano
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: