Bug 1837842 (CVE-2019-11048) - CVE-2019-11048 php: 2 integer wraparound when receiving multipart forms
Summary: CVE-2019-11048 php: 2 integer wraparound when receiving multipart forms
Keywords:
Status: NEW
Alias: CVE-2019-11048
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1837913 1837915 1837922 1837923 1837924 1837925 1838693 1837843 1837916 1837918 1837919 1837920 1837921
Blocks: 1837849
TreeView+ depends on / blocked
 
Reported: 2020-05-20 06:35 UTC by Marian Rehak
Modified: 2020-06-29 05:20 UTC (History)
9 users (show)

Fixed In Version: php 7.3.18, php php 7.2.31, php 7.4.6
Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in PHP under a non-default configuration, where it was vulnerable to integer wraparounds during the reception of a multipart POST request. This flaw allows a remote attacker to repeatedly crash PHP and fill the filesystem with temporary PHP files, resulting in a denial of service.
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)

Description Marian Rehak 2020-05-20 06:35:17 UTC
There are 2 integers wraparound flaws in php-src/main/rfc1867.c that allow a malicious user to crash PHP during a multipart/form-data file upload. A large multipart/form-data variable, or filename, may cause an integer overflow that leads to a subsequent crash.
Temporary files are not cleaned up, and could ultimately fill up the file system containing PHP temporary data.

Upstream Issues:

https://bugs.php.net/bug.php?id=78876
https://bugs.php.net/bug.php?id=78875

Comment 1 Marian Rehak 2020-05-20 06:35:36 UTC
Created php tracking bugs for this issue:

Affects: fedora-all [bug 1837843]

Comment 4 Joe Orton 2020-05-20 14:56:50 UTC
Note that this issue requires a pathological configuration to trigger; post_max_size must be set to 2GB or higher.  Such a configuration allows an effective Denial of Service attack against any server and should never be used in production.

Comment 5 Cedric Buissart 🐶 2020-05-21 13:03:18 UTC
Statement:

The severity of this issue is considered Moderate because it requires an unlikely large `post_max_size` to be configured.

Comment 6 Cedric Buissart 🐶 2020-05-21 13:03:21 UTC
Mitigation:

Ensure that `post_max_size` is set to a value less than 2GB, or remains default.


Note You need to log in before you can comment on or make changes to this bug.