You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2015/02/11 23:40:53 UTC
[Bug 57570] New: Make processing of chunked encoding trailers an
opt-in feature (align with HTTPD 2.4.12)
https://issues.apache.org/bugzilla/show_bug.cgi?id=57570
Bug ID: 57570
Summary: Make processing of chunked encoding trailers an opt-in
feature (align with HTTPD 2.4.12)
Product: Tomcat 8
Version: 8.0.18
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
Component: Connectors
Assignee: dev@tomcat.apache.org
Reporter: knst.kolinko@gmail.com
Two weeks ago Apache HTTPD 2.4.12 release was announced. It contains a fix for
the following issue:
<quote>
CVE-2013-5704 (cve.mitre.org)
core: HTTP trailers could be used to replace HTTP headers
late during request processing, potentially undoing or
otherwise confusing modules that examined or modified
request headers earlier. Adds "MergeTrailers" directive to restore
legacy behavior.
</quote>
-> [1],[2].
Apparently this has been discussed in the open for about a year in relation to
HTTPD [3] and in general [4], but I have not seen anyone raising the issue for
Tomcat yet.
In Tomcat chunked encoding trailers are processed by ChunkedInputFilter
(.parseEndChunk() -> .parseHeader()). The values are available as headers
(TestChunkedInputFilter$EchoHeaderServlet)
This was implemented via bug 49860 and is available since 6.0.30, 7.0.5 in all
current versions. (r1039090 in 6.0.x)
If we follow in HTTPD steps, a solution is to make processing of these trailers
an opt-in feature, being off by default. A mitigation is already available
with the existing features: it is possible to limit size of trailer headers via
configuration.
Tomcat 6: [5]
org.apache.coyote.MAX_TRAILER_SIZE=0
Tomcat 7 and later: [6]
maxTrailerSize="0" on an HTTP connector
In the simplest case "making processing of trailers an opt-in feature" means
changing the defaults for those options to be 0.
Note that setting those values to 0 does enforce the limit. It differs from
"just ignoring" the headers. So there is a place for having a separate option.
I think that if someone is actually using trailers, a better configuration
option would be a white list of expected trailer names, with non-whitelisted
trailers being ignored.
[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5704
[2] https://access.redhat.com/security/cve/CVE-2013-5704
[3] http://marc.info/?l=apache-httpd-dev&m=139636309822854&w=2
"CVE-2013-5704, mod_headers and chunked trailer fields"
mail thread, April 2014
[4] http://martin.swende.se/blog/HTTPChunked.html
"Chunked HTTP transfer encoding"
[5] http://tomcat.apache.org/tomcat-6.0-doc/config/systemprops.html#Other
[6]
http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Standard_Implementation
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57570] Make processing of chunked encoding trailers an opt-in
feature (align with HTTPD 2.4.12)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=57570
Konstantin Kolinko <kn...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
OS| |All
--- Comment #1 from Konstantin Kolinko <kn...@gmail.com> ---
The servlet specification (3.1) does not mention chunked encoding trailers. It
would be better if there were a separate API to access them. Treating trailers
as proper headers is a simplification, it hides the difference between them.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org