HTTP request smuggling bug patched in mitmproxy

Bug exploited inconsistencies between intermediary and backend servers

Mitmproxy, an open source, interactive HTTPS proxy service, has patched a dangerous bug that potentially allowed attackers to stage HTTP request smuggling attacks against backend servers.

HTTP request smuggling attacks exploit the inconsistencies between the way intermediary and backend servers process requests to bypass security controls, gain unauthorized access to sensitive data, or compromise other application users.

An elusive bug

Zhang Zeyu, the security researcher who reported the bug, discovered that an attacker could smuggle a request/response through mitmproxy as part of another request/response's HTTP message body.

“While the more obvious attack vectors (e.g., double Content-Length headers, using Content-Length over Transfer-Encoding) are rare nowadays, more subtle deviations from the standard leave certain setups equally vulnerable to request smuggling,” he told The Daily Swig.

BACKGROUND HTTP request smuggling: HTTP/2 opens a new attack tunnel

In the case of mitmproxy, an issue with the parsing of whitespace in header names resulted in mitmproxy and a downstream server possibly having different interpretations of HTTP headers.

“Eliminating this type of vulnerability is very tricky as you need different HTTP implementations (proxy and target server) to agree on a common interpretation of HTTP messages,” Maximilian Hils, the maintainer of mitmproxy, told The Daily Swig.

Alternatively, you can make the proxy reject potentially malformed messages, but that would have the drawback of imposing compatibility problems with clients in the wild, Hils said.

“This is not a buffer overflow, which has an obvious fix. There are a lot of nuances here to make sure that intermediary and servers agree,” he said.

HTTP/2 not affected

The bug only works against HTTP/1 services behind mitmproxy, which currently accounts for a very small number of web servers.

HTTP/2, the more commonly used protocol, does not rely on the use of Content-Length and Transfer-Encoding headers to determine where a request body ends.

Instead, a built-in length field is included in each data frame, and when proxies communicate with backends using HTTP/2, there is little ambiguity on the length of each message. Therefore, this particular request smuggling bug would be ineffective against HTTP/2 services.

Catch up on the latest security research news and analysis

HTTP/1 services that follow the RFC7230 specification and reject headers with whitespace would also be immune against the request smuggling bug found in mitmproxy. The security bug would also be useless to attackers if the target web application is not vulnerable in some other way.

“From a practical point of view, I'd argue that the impact is non-existent for the vast majority of users,” Hils said. “There are a lot of not-so-common preconditions that need to be met. I'd say quite a few stars need to align for this to have an actual impact in the wild.”

Edge cases

But Zeyu warned that many backend servers still fail to support HTTP/2, including Gunicorn, which serves many Python-based applications. And in many cases, services that support HTTP/2 are not configured to use it between the frontend proxy and the backend servers simply because most clients would not notice the difference, according to Zeyu.

“This means that there are still a lot of web proxy and server configurations that speak HTTP/2 between the client and the proxy but HTTP/1.x between the proxy and the backend, leaving room for HTTP request smuggling attacks to occur,” he said.

Irrespective of the debate about its seriousness, the bug has been patched in version 8.0 of mitmproxy.

YOU MAY ALSO LIKE Apple Safari empowers developers to mitigate web flaws with WebKit CSP enhancements