In Twisted Web through 19.10.0, there was an HTTP request splitting vulnerability. When presented with a content-length and a chunked encoding header, the content-length took precedence and the remainder of the request body was interpreted as a pipelined request.

In Twisted Web before 20.3.0, there was an HTTP request splitting vulnerability. When presented with two content-length headers, it ignored the first header. When the second content-length value was set to zero, the request body was interpreted as a pipelined request.

The Twisted Web HTTP 1.1 server, located in the twisted.web.http module, parsed several HTTP request constructs more leniently than permitted by RFC 7230:

1. The Content-Length header value could have a + or - prefix. 2. Illegal characters were permitted in chunked extensions, such as the LF (\n) character. 3. Chunk lengths, which are expressed in hexadecimal format, could have a prefix of 0x. 4. HTTP headers were stripped of all leading and trailing ASCII whitespace, rather than only space and HTAB (\t).

This non-conformant parsing can lead to desync if requests pass through multiple HTTP parsers, potentially resulting in HTTP request smuggling.

Impact

You may be affected if:

1. You use Twisted Web's HTTP 1.1 server and/or proxy 2. You also pass requests through a different HTTP server and/or proxy

The specifics of the other HTTP parser matter. The original report notes that some versions of Apache Traffic Server and HAProxy have been vulnerable in the past. HTTP request smuggling may be a serious concern if you use a proxy to perform request validation or access control.

The Twisted Web client is not affected. The HTTP 2.0 server uses a different parser, so it is not affected.

Patches

The issue has been addressed in Twisted 22.4.0rc1 and later.

Workarounds

Other than upgrading Twisted, you could:

Ensure any vulnerabilities in upstream proxies have been addressed, such as by upgrading them Filter malformed requests by other means, such as configuration of an upstream proxy

Credits

This issue was initially reported by Zhang Zeyu.

Python Twisted 14.0 trustRoot is not respected in HTTP client

Impact

Cookie and Authorization headers are leaked when following cross-origin redirects in twited.web.client.RedirectAgent and twisted.web.client.BrowserLikeRedirectAgent.

Impact

The Twisted SSH client and server implementation naively accepted an infinite amount of data for the peer's SSH version identifier.

A malicious peer can trivially craft a request that uses all available memory and crash the server, resulting in denial of service. The attack is as simple as nc -rv localhost 22 < /dev/zero.

Patches

The issue was fix in GitHub commit https://github.com/twisted/twisted/commit/98387b39e9f0b21462f6abc7a1325dc370fcdeb1

A fix is available in Twisted 22.2.0.

Workarounds

Limit access to the SSH server only to trusted source IP addresses. Connect over SSH only to trusted destination IP addresses.

References

Reported at https://twistedmatrix.com/trac/ticket/10284 Discussions at https://github.com/twisted/twisted/security/advisories/GHSA-rv6r-3f5q-9rgx

For more information

Found by vin01

Impact

Treq's request methods (treq.get, treq.post, HTTPClient.request, HTTPClient.get, etc.) accept cookies as a dictionary, for example:

py treq.get('https://example.com/', cookies={'session': '1234'})

Such cookies are not bound to a single domain, and are therefore sent to every domain ("supercookies"). This can potentially cause sensitive information to leak upon an HTTP redirect to a different domain., e.g. should https://example.com redirect to http://cloudstorageprovider.com the latter will receive the cookie session.

Patches

Treq 2021.1.0 and later bind cookies given to request methods (treq.request, treq.get, HTTPClient.request, HTTPClient.get, etc.) to the origin of the url parameter.

Workarounds

Instead of passing a dictionary as the cookies argument, pass a http.cookiejar.CookieJar instance with properly domain- and scheme-scoped cookies in it:

py from http.cookiejar import CookieJar from requests.cookies import createcookie

jar = CookieJar() jar.addcookie( createcookie( name='session', value='1234', domain='example.com', secure=True, ), ) client = HTTPClient(cookies=jar) client.get('https://example.com/')

References

Originally reported at huntr.dev A related issue in the handling of HTTP basic authentication was addressed in Twisted 22.1 (GHSA-92x2-jw7w-xvvx, CVE-2022-21712).

In words.protocols.jabber.xmlstream in Twisted through 19.2.1, XMPP support did not verify certificates when used with TLS, allowing an attacker to MITM connections.

A command injection vulnerability exists in TwistedWeb (version 14.0.0) due to improper input sanitization in the file upload functionality. An attacker can exploit this vulnerability by sending a specially crafted HTTP PUT request to upload a malicious file (e.g., a reverse shell script). Once uploaded, the attacker can trigger the execution of arbitrary commands on the target system, allowing for remote code execution. This could lead to escalation of privileges depending on the privileges of the web server process. The attack does not require physical access and can be conducted remotely, posing a significant risk to the confidentiality and integrity of the system.

In Twisted before 19.2.1, twisted.web did not validate or sanitize URIs or HTTP methods, allowing an attacker to inject invalid characters such as CRLF.

txAWS (all current versions) fail to perform complete certificate verification resulting in vulnerability to MitM attacks and information disclosure.

Twisted is an event-based framework for internet applications. Started with version 0.9.4, when the host header does not match a configured host twisted.web.vhost.NameVirtualHost will return a NoResource resource which renders the Host header unescaped into the 404 response allowing HTML and script injection. In practice this should be very difficult to exploit as being able to modify the Host header of a normal HTTP request implies that one is already in a privileged position. This issue was fixed in version 22.10.0rc1. There are no known workarounds.

Twisted before 16.3.1 does not attempt to address RFC 3875 section 4.1.18 namespace conflicts and therefore does not protect CGI applications from the presence of untrusted client data in the HTTPPROXY environment variable, which might allow remote attackers to redirect a CGI application's outbound HTTP traffic to an arbitrary proxy server via a crafted Proxy header in an HTTP request, aka an httpoxy issue.

Twisted is an event-based framework for internet applications. Prior to version 23.10.0rc1, when sending multiple HTTP requests in one TCP packet, twisted.web will process the requests asynchronously without guaranteeing the response order. If one of the endpoints is controlled by an attacker, the attacker can delay the response on purpose to manipulate the response of the second request when a victim launched two requests using HTTP pipeline. Version 23.10.0rc1 contains a patch for this issue.