<?xml version="1.0"?>
<!--

   Licensed to the Apache Software Foundation (ASF) under one or more
   contributor license agreements.  See the NOTICE file distributed with
   this work for additional information regarding copyright ownership.
   The ASF licenses this file to You under the Apache License, Version 2.0
   (the "License"); you may not use this file except in compliance with
   the License.  You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.
-->
<document>
    <properties>
        <title>Commons FileUpload Security Reports</title>
        <author email="dev@commons.apache.org">Commons Documentation Team</author>
    </properties>
    <body>
      <section name="Apache Commons FileUpload Security Vulnerabilities">
        <p>This page lists all security vulnerabilities fixed in
        released versions of Apache Commons FileUpload. Each
        vulnerability is given a security impact rating by the
        development team - please note that this rating may vary from
        platform to platform. We also list the versions of Commons
        FileUpload the flaw is known to affect, and where a flaw has not
        been verified list the version with a question mark.</p>

        <p>Please note that binary patches are never provided. If you
        need to apply a source code patch, use the building
        instructions for the Commons FileUpload version that you are
        using.</p>

        <p>If you need help on building Commons FileUpload or other help
        on following the instructions to mitigate the known
        vulnerabilities listed here, please send your questions to the
        public <a href="mail-lists.html">Commons Users mailing
        list</a>.</p>

        <p>If you have encountered an unlisted security vulnerability
        or other unexpected behaviour that has security impact, or if
        the descriptions here are incomplete, please report them
        privately to the Apache Security Team. Thank you.</p>

        <p>For information about reporting or asking questions about
        security problems, please see the <a
        href="https://commons.apache.org/security.html">security page
        of the Apache Commons project</a>.</p>

        <subsection name="Notes on Apache Commons FileUpload 1.3.3">
          <p>
            Regarding potential security problems with the class called DiskFileItem,
            it is true, that this class exists, and can be serialized/deserialized in FileUpload versions, up to, and
            including 1.3.2. It is also true, that a malicious attacker can abuse this possibility to create abitraryly
            located files (assuming the required permissions) with arbitrary contents, if he gets the opportunity to
            provide specially crafted data, which is being deserialized by a Java application, which has either of the
            above versions of Commons FileUpload in the classpath, and which puts no limitations on the classes being
            deserialized.
          </p>
          <p>
            That being said, we (the Apache Commons team) hold the view, that the actual problem is not the DiskFileItem
            class, but the "if" in the previous sentence. A Java application should carefully consider, which classes
            can be deserialized. A typical approach would be, for example, to provide a blacklist, or whitelist of
            packages, and/or classes, which may, or may not be deserialized.
          </p>
          <p>
            On the other hand, we acknowledge, that the likelyhood of application container vendors taking such a
            simple security measure is extremely low. So, in order to support the Commons Fileupload users, we have
            decided to choose a different approach:
          </p>
          <p>
            Beginning with 1.3.3, the class DiskFileItem is still implementing the interface java.io.Serializable.
            In other words, it still declares itself as serializable, and deserializable to the JVM. In practice,
            however, an attempt to deserialize an instance of DiskFileItem will trigger an Exception. In the unlikely
            case, that your application depends on the deserialization of DiskFileItems, you can revert to the
            previous behaviour by setting the system property "org.apache.commons.fileupload.disk.DiskFileItem.serializable"
            to "true".
          </p>
        </subsection>

        <subsection name="Fixed in Apache Commons FileUpload 1.3.2">
          <p><b>Low: Denial of Service</b> <a
          href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3092">CVE-2016-3092</a></p>
 
          <p>Specially crafted input can trigger a DoS (slow uploads), if the size of the MIME
          boundary is close to the size of the buffer in MultipartStream. This is also fixed
          for <a href="https://tomcat.apache.org/security.html">Apache Tomcat</a>.</p>

          <p>This was fixed in revisions
          <a href="http://svn.apache.org/viewvc?view=revision&amp;revision=1743480">1743480</a>.</p>

          <p>Affects: 1.0? - 1.3.1</p>
        </subsection>

        <subsection name="Fixed in Apache Commons FileUpload 1.3.1">
          <p><b>Low: Denial of Service</b> <a
          href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=2014-0050">CVE-2014-0050</a></p>

          <p>MultipartStream.java in Apache Commons FileUpload before 1.3.1, as used in
          <a href="https://tomcat.apache.org/security.html">Apache Tomcat</a>,
          JBoss Web, and other products, allows remote attackers to cause a denial of service (infinite
          loop and CPU consumption) via a crafted Content-Type header that bypasses a loop's intended
          exit conditions.</p>

          <p>This was fixed in revisions
          <a href="http://svn.apache.org/viewvc?view=revision&amp;revision=1565143">1565143</a>.</p>

          <p>Affects: 1.0? - 1.3</p>
        </subsection>

        <subsection name="Fixed in Apache Commons FileUpload 1.3">

          <p><b>Low: Improved Documentation for Multitenancy</b> <a
          href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=2013-0248">CVE-2013-0248</a></p>

          <p>Update the Javadoc and documentation to make it clear that setting a repository
          is required for a secure configuration if there are local, untrusted users.</p>

          <p>This was fixed in revisions
          <a href="http://svn.apache.org/viewvc?view=revision&amp;revision=1453273">1453273</a>.</p>

          <p>Affects: 1.0 - 1.2.2</p>
        </subsection>

		</section>

      <section name="Errors and Ommissions">
        <p>Please report any errors or omissions to <a
        href="mail-lists.html">the dev mailing list</a>.</p>
      </section>
    </body>
</document>