Bug 2278710 (CVE-2024-30251)
Summary: | CVE-2024-30251 aiohttp: DoS when trying to parse malformed POST requests | ||
---|---|---|---|
Product: | [Other] Security Response | Reporter: | Zack Miele <zmiele> |
Component: | vulnerability | Assignee: | Product Security <prodsec-ir-bot> |
Status: | NEW --- | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | unspecified | CC: | bbuckingham, bcourt, caswilli, code, davidn, dfreiber, drow, ehelms, epacific, gtanzill, hkataria, jburrell, jcammara, jhardy, jmitchel, jneedle, jobarker, jsherril, jtanner, kaycoth, kshier, lzap, mabashia, mhulan, mminar, nmoumoul, orabin, osapryki, pcreech, psegedy, rbiba, rbobbitt, rchan, sidakwo, simaishi, smcdonal, sskracic, stcannon, teagle, vkumar, yguenane, zsadeh |
Target Milestone: | --- | Keywords: | Security |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | aiohttp 3.9.4 | Doc Type: | --- |
Doc Text: |
An infinite loop flaw was found in aiohttp when handling POST (multipart/form-data) requests. This flaw allows an attacker to send a specially crafted request, leading the server to enter an infinite loop and render it unable to process any further requests. This denial of service can be triggered by a single unauthenticated POST request.
AIOHTTP handles multipart strings through a process of segmenting them into chunks. The reading of each chunk is performed under the control of an asynchronous wait, ensuring that the operation completes before proceeding. A vulnerability was identified where a specially crafted request could trigger an infinite loop due to improper detection of the end-of-file (EOF) marker within the content.
The resolution involves the implementation of an enhanced checking mechanism. This mechanism correctly assigns the EOF marker to the chunk in question upon the successful completion of content reading, thereby preventing the infinite loop scenario.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | Type: | --- | |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 2278714, 2278716, 2278717, 2278718, 2278719, 2278720, 2278721, 2278722, 2278723, 2278724, 2278725, 2278726, 2278727, 2278728, 2278729 | ||
Bug Blocks: | 2278711 |
Description
Zack Miele
2024-05-02 20:02:17 UTC
Created python-aiohttp tracking bugs for this issue: Affects: epel-8 [bug 2278724] Affects: fedora-38 [bug 2278714] Affects: fedora-39 [bug 2278725] Affects: fedora-40 [bug 2278726] Created python-gcsfs tracking bugs for this issue: Affects: fedora-38 [bug 2278717] Affects: fedora-39 [bug 2278720] Affects: fedora-40 [bug 2278722] Created python-idna-ssl tracking bugs for this issue: Affects: epel-8 [bug 2278716] Affects: fedora-38 [bug 2278718] Affects: fedora-39 [bug 2278721] Affects: fedora-40 [bug 2278723] Created python-pytelegrambotapi tracking bugs for this issue: Affects: fedora-38 [bug 2278719] It would be great if someone or something could check these CVE bugs against the version number in the advisory, where applicable. The text here clearly states “This issue has been addressed in version 3.9.4.” All Fedora releases have 3.9.5. Furthermore, I can’t figure out the rationale for filing bugs against the other packages: python-gcsfs, python-idna-ssl, and python-pytelegrambotapi. These packages simply depend on aiohttp and have no indication of bundling. But there are many other packages that depend on aiohttp and did not have bugs filed (and it doesn’t make sense to file bugs for dependent packages anyway – what are they supposed to do?) so it still doesn’t make sense. It seems like the scripts for filing these bugs are flawed, and nobody is double-checking them. Between bugs filed against unaffected versions and bugs filed for packages that merely depend on aiohttp, I count eleven totally spurious bugs that could have been avoided by a better bug-filing process, but now have to be individually looked at and closed by maintainers. Only bug 2278724 for aiohttp in EPEL8 is legitimate. Mass-filing poorly-targeted bugs for every new CVE without the most rudimentary checking risks training maintainers to simply ignore these bugs, which is a shame, because they *can* be a useful service. This issue has been addressed in the following products: Red Hat Ansible Automation Platform 2.4 for RHEL 9 Red Hat Ansible Automation Platform 2.4 for RHEL 8 Via RHSA-2024:3781 https://access.redhat.com/errata/RHSA-2024:3781 |