libcommons-fileupload-java: CVE-2023-24998

Debian Bug report logs - #1031733
libcommons-fileupload-java: CVE-2023-24998

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Moritz Mühlenhoff <jmm@inutil.org>

To: submit@bugs.debian.org

Subject: libcommons-fileupload-java: CVE-2023-24998

Date: Tue, 21 Feb 2023 16:10:16 +0100

Source: libcommons-fileupload-java
X-Debbugs-CC: team@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for libcommons-fileupload-java.

CVE-2023-24998[0]:
| Apache Commons FileUpload before 1.5 does not 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.

https://lists.apache.org/thread/4xl4l09mhwg4vgsk7dxqogcjrobrrdoy
https://github.com/apache/commons-fileupload/commit/e20c04990f7420ca917e96a84cec58b13a1b3d17


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-24998
    https://www.cve.org/CVERecord?id=CVE-2023-24998

Please adjust the affected versions in the BTS as needed.

Message #14 received at 1031733@bugs.debian.org (full text, mbox, reply):

From: tony mancill <tmancill@debian.org>

To: Moritz Mühlenhoff <jmm@inutil.org>, 1031733@bugs.debian.org

Subject: Re: Bug#1031733: libcommons-fileupload-java: CVE-2023-24998

Date: Tue, 21 Feb 2023 21:48:35 -0800

[Message part 1 (text/plain, inline)]

On Tue, Feb 21, 2023 at 04:10:16PM +0100, Moritz Mühlenhoff wrote:
> Source: libcommons-fileupload-java
> X-Debbugs-CC: team@security.debian.org
> Severity: important
> Tags: security
> 
> Hi,
> 
> The following vulnerability was published for libcommons-fileupload-java.
> 
> CVE-2023-24998[0]:
> | Apache Commons FileUpload before 1.5 does not 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.
> 
> https://lists.apache.org/thread/4xl4l09mhwg4vgsk7dxqogcjrobrrdoy
> https://github.com/apache/commons-fileupload/commit/e20c04990f7420ca917e96a84cec58b13a1b3d17

I have a patched version of 1.4 ready to upload using the upstream
patch.  However, based on reading the thread above, having the ability
to limit the number of request parts is in the library is not the same
as actually limiting the request parts.  The patched library defaults to
an unlimited number, so it is necessary but not sufficient to mitigate
the risk.

Is it safe to assume that CVEs will be created for the software
components that use commons-fileupload, and so I can go ahead and upload
the patched 1.4 version and mark CVE-2023-24998 as complete?

Thanks,
tony

[signature.asc (application/pgp-signature, inline)]

Message #19 received at 1031733@bugs.debian.org (full text, mbox, reply):

From: Moritz Muehlenhoff <jmm@inutil.org>

To: tony mancill <tmancill@debian.org>

Cc: 1031733@bugs.debian.org

Subject: Re: Bug#1031733: libcommons-fileupload-java: CVE-2023-24998

Date: Wed, 22 Feb 2023 12:12:47 +0100

On Tue, Feb 21, 2023 at 09:48:35PM -0800, tony mancill wrote:
> On Tue, Feb 21, 2023 at 04:10:16PM +0100, Moritz Mühlenhoff wrote:
> > Source: libcommons-fileupload-java
> > X-Debbugs-CC: team@security.debian.org
> > Severity: important
> > Tags: security
> > 
> > Hi,
> > 
> > The following vulnerability was published for libcommons-fileupload-java.
> > 
> > CVE-2023-24998[0]:
> > | Apache Commons FileUpload before 1.5 does not 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.
> > 
> > https://lists.apache.org/thread/4xl4l09mhwg4vgsk7dxqogcjrobrrdoy
> > https://github.com/apache/commons-fileupload/commit/e20c04990f7420ca917e96a84cec58b13a1b3d17
> 
> I have a patched version of 1.4 ready to upload using the upstream
> patch.  However, based on reading the thread above, having the ability
> to limit the number of request parts is in the library is not the same
> as actually limiting the request parts.  The patched library defaults to
> an unlimited number, so it is necessary but not sufficient to mitigate
> the risk.
> 
> Is it safe to assume that CVEs will be created for the software
> components that use commons-fileupload, and so I can go ahead and upload
> the patched 1.4 version and mark CVE-2023-24998 as complete?

We can consider CVE-2023-24998 by itself as fixed with your backport, it happens
from time to time that a fix requires a new API or other related changes on the
calling side of a function.

Adapting a codebase to the new function is outside the scope of the CVE system,
if we know any reverse dependency which needs to set fileCountMax, we can patch
it, but often such a setting is also highly dependent on the setup and a site-specific
setting.

Cheers,
        Moritz

Send a report that this bug log contains spam.