Incorrect Handling Of Transfer-Encoding Header
Description of Vulnerability
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.
Severity
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).
Impact
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:
-
use a vulnerable version of Akka HTTP
-
the application must proxy requests to a backend server
-
the backend server must have another bug that accepts the message and interprets the malformed message as two messages
Resolution
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.
Acknowledgements
Thanks, Bastian Ike and Sebastian Rose of AOE for bringing this issue to our attention.