ghsa-4ppp-gpcr-7qf6
Vulnerability from github
Published
2019-12-20 23:04
Modified
2022-03-24 17:52
Summary
HTTP Request Smuggling: Content-Length Sent Twice in Waitress
Details

Impact

Waitress would header fold a double Content-Length header and due to being unable to cast the now comma separated value to an integer would set the Content-Length to 0 internally.

So a request with:

Content-Length: 10 Content-Length: 10

would get transformed to:

Content-Length: 10, 10

Which would Waitress would then internally set to Content-Lenght: 0.

Waitress would then treat the request as having no body, thereby treating the body of the request as a new request in HTTP pipelining.

Patches

This issue is fixed in Waitress 1.4.0. This brings a range of changes to harden Waitress against potential HTTP request confusions, and may change the behaviour of Waitress behind non-conformist proxies.

The Pylons Project recommends upgrading as soon as possible, while validating that the changes in Waitress don't cause any changes in behavior.

Workarounds

Various reverse proxies may have protections against sending potentially bad HTTP requests to the backend, and or hardening against potential issues like this. If the reverse proxy doesn't use HTTP/1.1 for connecting to the backend issues are also somewhat mitigated, as HTTP pipelining does not exist in HTTP/1.0 and Waitress will close the connection after every single request (unless the Keep Alive header is explicitly sent... so this is not a fool proof security method).

Issues/more security issues:

  • open an issue at https://github.com/Pylons/waitress/issues (if not sensitive or security related)
  • email the Pylons Security mailing list: pylons-project-security@googlegroups.com (if security related)
Show details on source website

To clipboard 

{
  "affected": [
    {
      "ecosystem_specific": {
        "affected_functions": [
          "waitress.parser.HTTPRequestParser.parse_header"
        ]
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "waitress"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2019-12-20T23:02:03Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Impact\n\nWaitress would header fold a double `Content-Length` header and due to being unable to cast the now comma separated value to an integer would set the `Content-Length` to 0 internally.\n\nSo a request with:\n\n```\nContent-Length: 10\nContent-Length: 10\n```\n\nwould get transformed to:\n\n```\nContent-Length: 10, 10\n```\n\nWhich would Waitress would then internally set to `Content-Lenght: 0`.\n\nWaitress would then treat the request as having no body, thereby treating the body of the request as a new request in HTTP pipelining.\n\n### Patches\n\nThis issue is fixed in Waitress 1.4.0. This brings a range of changes to harden Waitress against potential HTTP request confusions, and may change the behaviour of Waitress behind non-conformist proxies. \n\nThe Pylons Project recommends upgrading as soon as possible, while validating that the changes in Waitress don\u0027t cause any changes in behavior.\n\n### Workarounds\n\nVarious reverse proxies may have protections against sending potentially bad HTTP requests to the backend, and or hardening against potential issues like this. If the reverse proxy doesn\u0027t use HTTP/1.1 for connecting to the backend issues are also somewhat mitigated, as HTTP pipelining does not exist in HTTP/1.0 and Waitress will close the connection after every single request (unless the Keep Alive header is explicitly sent... so this is not a fool proof security method).\n\n### Issues/more security issues:\n\n* open an issue at https://github.com/Pylons/waitress/issues (if not sensitive or security related)\n* email the Pylons Security mailing list: pylons-project-security@googlegroups.com (if security related)",
  "id": "GHSA-4ppp-gpcr-7qf6",
  "modified": "2022-03-24T17:52:19Z",
  "published": "2019-12-20T23:04:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Pylons/waitress/security/advisories/GHSA-4ppp-gpcr-7qf6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Pylons/waitress/commit/575994cd42e83fd772a5f7ec98b2c56751bd3f65"
    },
    {
      "type": "WEB",
      "url": "https://docs.pylonsproject.org/projects/waitress/en/latest/#security-fixes"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Pylons/waitress"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-j7j6-7hfx-5522"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/waitress/PYSEC-2020-178.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "HTTP Request Smuggling: Content-Length Sent Twice in Waitress"
}


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.