src/site/xdoc/security-reports.xml - commons-fileupload - Git at Google

 <?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>
	<?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&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&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&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>