156 lines
7.9 KiB
XML
156 lines
7.9 KiB
XML
<?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="http://commons.apache.org/security.html">security page
|
|
of the Apache Commons project</a>.</p>
|
|
|
|
<subsection name="Fixed in Apache Commons FileUpload 1.5">
|
|
<p><b>Important: Denial of Service</b> <a
|
|
href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-24998">CVE-2023-24998</a></p>
|
|
|
|
<p>Apache Commons FileUpload before 1.5 does not provide an option to
|
|
limit the number of request parts to be processed resulting in the
|
|
possibility of an attacker triggering a DoS with a malicious upload or
|
|
series of uploads. Note that, like all of the file upload limits, the
|
|
new configuration option (FileUploadBase#setFileCountMax) is not
|
|
enabled by default and must be explicitly configured.</p>
|
|
|
|
<p>This was fixed in commit
|
|
<a href="https://github.com/apache/commons-fileupload/commit/e20c04990f7420ca917e96a84cec58b13a1b3d17"
|
|
>e20c0499</a>.</p>
|
|
|
|
<p>Affects: 1.0? - 1.4</p>
|
|
</subsection>
|
|
|
|
<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 revision
|
|
<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 revision
|
|
<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 revision
|
|
<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>
|