2021-02-24
HTTP/1.1 defines rules which Transfer-Encoding headers are valid and how they should be interpreted. In particular, a Transfer-Encoding: chunked header and a Content-Length header
are not allowed to appear in a single message at the same time. This is important to unambiguously delimit subsequent HTTP messages on a connection.
In theory, HTTP/1.1 allows multiple encodings, although, in practice, only chunked is relevant. In the case that multiple encodings are present,
vulnerable versions of Akka HTTP do not correctly validate the rules of the specification and effectively ignore the Transfer-Encoding header, use
a Content-Length header if present for delimiting a message, and pass the message to the user unchanged.
If users used Akka HTTP as a reverse proxy, such a message might be forwarded to a backend server. This can potentially lead to “Request Smuggling” if the backend server has a similar but different interpretation for that (invalid) set of headers.
Based on our assessment, the CVSS score of this vulnerability is 4.2 (Medium), based on vector (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N/E:U/RL:O/RC:C).
A vulnerable Akka HTTP server will accept a malformed message as described above and hand it over to the user. If the user application proxies this message to another server unchanged and that server also accepts that message but interprets it as two HTTP messages, the second message has reached the second server without having been inspected by the proxy.
Note that Akka HTTP itself currently does not provide functionality to proxy requests to other servers (but it’s easy to build).
In summary, these conditions must be true for an application to be vulnerable:
Akka HTTP will no longer accept multiple encodings in Transfer-Encoding but only a single chunked encoding is valid. HTTP message carrying a combination of Transfer-Encoding and
Content-Length headers are rejected.
10.2.4 and 10.1.1410.2.410.1.14Thanks, Bastian Ike and Sebastian Rose of AOE for bringing this issue to our attention.