Bug 57570 - Make processing of chunked encoding trailers an opt-in feature (align with HTTPD 2.4.12)
Summary: Make processing of chunked encoding trailers an opt-in feature (align with HT...
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Connectors (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal (vote)
Target Milestone: ----
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-11 22:40 UTC by Konstantin Kolinko
Modified: 2015-04-02 12:51 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Konstantin Kolinko 2015-02-11 22:40:53 UTC
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
Comment 1 Konstantin Kolinko 2015-02-11 23:27:16 UTC
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.
Comment 2 Mark Thomas 2015-03-03 20:10:00 UTC
RFC 7230 has added additional constraints [1] for the handling of trailers.

[1] http://tools.ietf.org/html/rfc7230#page-37
Comment 3 Mark Thomas 2015-03-13 11:13:42 UTC
Fixed in trunk, 8.0.x (for 8.0.21 onwards) and 7.0.x (for 7.0.60 onwards) and proposed for 6.0.x.
Comment 4 Mark Thomas 2015-04-02 12:51:44 UTC
Fixed in 6.0.x for 6.0.44 onwards.