GHSA-gjcc-jvgw-wvwj
Vulnerability from github
Published
2024-11-20 21:38
Modified
2024-11-20 21:38
Severity ?
8.2 (High) - CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L
Summary
Litestar allows unbounded resource consumption (DoS vulnerability)
Details

Summary

Litestar offers multiple methods to return a parsed representation of the request body, as well as extractors that rely on those parsers to map request content to structured data types. Multiple of those parsers do not have size limits when reading the request body into memory, which allows an attacker to cause excessive memory consumption on the server by sending large requests.

Details

The Request methods to parse json, msgpack or form-data all read the entire request stream into memory via await self.body() without a prior size check or size limit. There may be other places (e.g. extractors) where this can happen.

For most formats, a configurable size limit would be sufficient to mitigate this issue. The total request size can also be limited by a proxy (e.g. nginx) in front of the actual application as a workaround. However, for applications that actually want to accept large file uploads via multipart/form-data, a simple size limit would not be practical. The multipart parser currently used by Litestar expects a single byte string as input and does not support incremental parsing via Request.stream(). Applications could bypass the Litestar parser and use a streaming parser to read from Request.stream() instead, but that would not work with extractors and other features of the framework. Switching the parser for a different implementation is currently not possible via public APIs.

PoC

Start an applications that accesses Request.json(), Request.msgpack() or Request.form() or uses an extractor that relies on those parsers internally, and send a large request with a matching content type. The actual content of the request does not matter. For example: curl -F "foo=</dev/random" http://127.0.0.1:8000/) for multipart/form-data. Server memory consumption will increase very quickly until memory (and swap) are exhausted.

Impact

This is a denial of service (DoS) vulnerability affecting all Litestar applications that process json, msgpack or form-data submission requests.

Show details on source website

To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "litestar"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.12.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-52581"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-11-20T21:38:58Z",
    "nvd_published_at": "2024-11-20T21:15:08Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nLitestar offers multiple methods to return a parsed representation of the request body, as well as extractors that rely on those parsers to map request content to structured data types. Multiple of those parsers do not have size limits when reading the request body into memory, which allows an attacker to cause excessive memory consumption on the server by sending large requests.\n\n### Details\nThe `Request` methods to parse json, msgpack or form-data all read the entire request stream into memory via `await self.body()` without a prior size check or size limit. There may be other places (e.g. extractors) where this can happen.\n\nFor most formats, a configurable size limit would be sufficient to mitigate this issue. The total request size can also be limited by a proxy (e.g. nginx) in front of the actual application as a workaround. However, for applications that actually want to accept large file uploads via `multipart/form-data`, a simple size limit would not be practical. The multipart parser currently used by Litestar expects a single byte string as input and does not support incremental parsing via `Request.stream()`. Applications could bypass the Litestar parser and use a [streaming parser](https://pypi.org/project/multipart/) to read from `Request.stream()` instead, but that would not work with extractors and other features of the framework. Switching the parser for a different implementation is currently not possible via public APIs.\n\n### PoC\nStart an applications that accesses `Request.json()`, `Request.msgpack()` or `Request.form()` or uses an extractor that relies on those parsers internally, and send a large request with a matching content type. The actual content of the request does not matter. For example: `curl -F \"foo=\u003c/dev/random\" http://127.0.0.1:8000/`) for `multipart/form-data`. Server memory consumption will increase very quickly until memory (and swap) are exhausted.\n\n### Impact\nThis is a denial of service (DoS) vulnerability affecting all Litestar applications that process json, msgpack or form-data submission requests.\n",
  "id": "GHSA-gjcc-jvgw-wvwj",
  "modified": "2024-11-20T21:38:58Z",
  "published": "2024-11-20T21:38:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/litestar-org/litestar/security/advisories/GHSA-gjcc-jvgw-wvwj"
    },
    {
      "type": "WEB",
      "url": "https://github.com/litestar-org/litestar/security/advisories/GHSA-p24m-863f-fm6q)"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52581"
    },
    {
      "type": "WEB",
      "url": "https://github.com/litestar-org/litestar/commit/53c1473b5ff7502816a9a339ffc90731bb0c2138"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/litestar-org/litestar"
    },
    {
      "type": "WEB",
      "url": "https://github.com/litestar-org/litestar/blob/main/litestar/_multipart.py#L97"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Litestar allows unbounded resource consumption (DoS vulnerability) "
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.