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

[Moritz Muehlenhoff]

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 at 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