Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[GHSA-q34m-jh98-gwm2] Werkzeug possible resource exhaustion when parsing file data in forms #5124

Merged
merged 1 commit into from
Dec 27, 2024
+12 −11
Merged

[GHSA-q34m-jh98-gwm2] Werkzeug possible resource exhaustion when parsing file data in forms #5124

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 12 additions & 11 deletions advisories/github-reviewed/2024/10/GHSA-q34m-jh98-gwm2/GHSA-q34m-jh98-gwm2.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,13 +9,9 @@
"summary": "Werkzeug possible resource exhaustion when parsing file data in forms",
"details": "Applications using Werkzeug to parse `multipart/form-data` requests are vulnerable to resource exhaustion. A specially crafted form body can bypass the `Request.max_form_memory_size` setting.\n\nThe `Request.max_content_length` setting, as well as resource limits provided by deployment software and platforms, are also available to limit the resources used during a request. This vulnerability does not affect those settings. All three types of limits should be considered and set appropriately when deploying an application.",
"severity": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
},
{
"type": "CVSS_V4",
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:U"
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N"
}
],
"affected": [
Expand Down Expand Up @@ -54,14 +50,11 @@
"introduced": "0"
},
{
"fixed": "0.19.7"
"fixed": "0.20.0"
}
]
}
],
"database_specific": {
"last_known_affected_version_range": "<= 0.19.6"
}
]
}
],
"references": [
Expand All @@ -77,10 +70,18 @@
"type": "WEB",
"url": "https://github.com/pallets/quart/commit/5e78c4169b8eb66b91ead3e62d44721b9e1644ee"
},
{
"type": "WEB",
"url": "https://github.com/pallets/quart/commit/abb04a512496206de279225340ed022852fbf51f"
},
{
"type": "WEB",
"url": "https://github.com/pallets/werkzeug/commit/50cfeebcb0727e18cc52ffbeb125f4a66551179b"
},
{
"type": "WEB",
"url": "https://github.com/pallets/quart/releases/tag/0.20.0"
},
{
"type": "PACKAGE",
"url": "https://github.com/pallets/werkzeug"
Expand All @@ -94,7 +95,7 @@
"cwe_ids": [
"CWE-400"
],
"severity": "MODERATE",
"severity": "HIGH",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This shouldn't be HIGH, I presume this was a mistake?

Copy link
Author

@defnull defnull Dec 27, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes and no. The "Suggest improvements for this vulnerability" form marked the unchanged CVSSv4 string as invalid, probably because it does not yet support the E flag. I just toggled one of the options back and forth to get a valid string again, which removed the E:U and also the CVSSv3 score. The form seems to be quite destructive. But the available flags are all correct and unchanged, and the score "8.7 / High" matches the CVSSv4 string.

The E:U flag means "There is no exploit yet" which lowered the score, but was wrong. There was a working PoC in the original report, before the report text was completely re-written by David. The flag should be E:P and that would results in a "High" classification again.

So, this was a 'happy accident'. Unintentional, but still correct.

Copy link
Contributor

@shelbyc shelbyc Dec 27, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The CVSSv4 value in GHSA-q34m-jh98-gwm2 and the corresponding record for https://nvd.nist.gov/vuln/detail/CVE-2024-49767 is https://www.first.org/cvss/calculator/v4-0#CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N , which corresponds to 6.9 / Medium. The value that is currently in the advisory is https://www.first.org/cvss/calculator/v4-0#CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:U, which corresponds to 6.6 / Medium.

The CVSS 3.1 value, which was provided by NVD rather than the maintainer or GitHub, is https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H , which corresponds to 7.5 / High. NVD generally uses a "worst case scenario" approach to CVSS scoring, which sometimes leads to higher severity assessments than those chosen by the maintainers or CVE Numbering Authorities.

I can correct the CVSS to https://www.first.org/cvss/calculator/v4-0#CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N to align with the repository advisory and CVE record.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's strange, look at the diff of this PR. The "Availability (VA)" rating in the GHSA json file was "High", not "Low". I did not change that aspect of the CVSS. The NIST listing also contains a different text (one that is more close to the original report, not the last-minute change made by David). Looks like the CVE was generated from an older version of the GHSA. So, what's correct? The exploit can be used to crash the server process (with OOM errors). That sounds pretty "Availability (VA): High" to me.

"github_reviewed": true,
"github_reviewed_at": "2024-10-25T19:44:43Z",
"nvd_published_at": "2024-10-25T20:15:04Z"
Expand Down
Loading