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

              depends on

              Bug - A problem which impairs or prevents the functions of the product. ICE-10023 Fix CVE-2014-0050 DoS with malformed Content-Type header and multipart request processing

              • Major - Major loss of function.
              • Closed

                Activity

                Hide
                Permalink
                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)

                  People

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

                    Dates

                    • Created:
                      Updated:
                      Resolved: