ghsa-qw69-rqj8-6qw8
Vulnerability from github
Published
2023-04-19 18:15
Modified
2023-04-19 18:15
Severity ?
5.3 (Medium) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Summary
OutOfMemoryError for large multipart without filename in Eclipse Jetty
Details

Impact

Servlets with multipart support (e.g. annotated with @MultipartConfig) that call HttpServletRequest.getParameter() or HttpServletRequest.getParts() may cause OutOfMemoryError when the client sends a multipart request with a part that has a name but no filename and a very large content.

This happens even with the default settings of fileSizeThreshold=0 which should stream the whole part content to disk.

An attacker client may send a large multipart request and cause the server to throw OutOfMemoryError. However, the server may be able to recover after the OutOfMemoryError and continue its service -- although it may take some time.

A very large number of parts may cause the same problem.

Patches

Patched in Jetty versions

  • 9.4.51.v20230217 - via PR #9345
  • 10.0.14 - via PR #9344
  • 11.0.14 - via PR #9344

Workarounds

Multipart parameter maxRequestSize must be set to a non-negative value, so the whole multipart content is limited (although still read into memory). Limiting multipart parameter maxFileSize won't be enough because an attacker can send a large number of parts that summed up will cause memory issues.

References

  • https://github.com/eclipse/jetty.project/issues/9076
  • https://github.com/jakartaee/servlet/blob/6.0.0/spec/src/main/asciidoc/servlet-spec-body.adoc#32-file-upload
Show details on source website

To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty:jetty-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "9.4.51.v20230217"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty:jetty-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0"
            },
            {
              "fixed": "10.0.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty:jetty-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0"
            },
            {
              "fixed": "11.0.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-26048"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-04-19T18:15:45Z",
    "nvd_published_at": "2023-04-18T21:15:08Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nServlets with multipart support (e.g. annotated with `@MultipartConfig`) that call `HttpServletRequest.getParameter()` or `HttpServletRequest.getParts()` may cause `OutOfMemoryError` when the client sends a multipart request with a part that has a name but no filename and a very large content.\n\nThis happens even with the default settings of `fileSizeThreshold=0` which should stream the whole part content to disk.\n\nAn attacker client may send a large multipart request and cause the server to throw `OutOfMemoryError`.\nHowever, the server may be able to recover after the `OutOfMemoryError` and continue its service -- although it may take some time.\n\nA very large number of parts may cause the same problem.\n\n### Patches\nPatched in Jetty versions\n\n* 9.4.51.v20230217 - via PR #9345\n* 10.0.14 - via PR #9344\n* 11.0.14 - via PR #9344\n\n### Workarounds\nMultipart parameter `maxRequestSize` must be set to a non-negative value, so the whole multipart content is limited (although still read into memory).\nLimiting multipart parameter `maxFileSize` won\u0027t be enough because an attacker can send a large number of parts that summed up will cause memory issues.\n\n### References\n* https://github.com/eclipse/jetty.project/issues/9076\n* https://github.com/jakartaee/servlet/blob/6.0.0/spec/src/main/asciidoc/servlet-spec-body.adoc#32-file-upload\n",
  "id": "GHSA-qw69-rqj8-6qw8",
  "modified": "2023-04-19T18:15:45Z",
  "published": "2023-04-19T18:15:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/eclipse/jetty.project/security/advisories/GHSA-qw69-rqj8-6qw8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26048"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eclipse/jetty.project/issues/9076"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eclipse/jetty.project/pull/9344"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eclipse/jetty.project/pull/9345"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/eclipse/jetty.project"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eclipse/jetty.project/releases/tag/jetty-9.4.51.v20230217"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jakartaee/servlet/blob/6.0.0/spec/src/main/asciidoc/servlet-spec-body.adoc#32-file-upload"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/09/msg00039.html"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20230526-0001"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2023/dsa-5507"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OutOfMemoryError for large multipart without filename in Eclipse Jetty"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




  • 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.