#1729: Incorrect parsing of responses containing both chunked transfer-encoding
and Content-length
----------------------+----------------------
Reporter: regilero | Type: defect
Status: new | Priority: normal
Milestone: | Component: varnishd
Version: 4.0.3 | Severity: normal
Keywords: |
----------------------+----------------------
RFC 7230:
> A sender MUST NOT send a Content-Length header field in any message
> that contains a Transfer-Encoding header field.
> (...)
So having a backend response with both headers is an issue on the backend
side.
It means this is not a security issue for varnish.
But when it happens:
RFC 7230:
> If a message is received with both a Transfer-Encoding and a
> Content-Length header field, the Transfer-Encoding overrides the
> Content-Length. Such a message might indicate an attempt to
> perform request smuggling (Section 9.5) or response splitting
> (Section 9.4) and ought to be handled as an error. A sender MUST
> remove the received Content-Length field prior to forwarding such
> a message downstream.
In varnish 4.0.3, maybe because of #1506 and https://www.varnish-
cache.org/trac/changeset/535d44b8909ee88e8700a35bed79f9ca77e445a4 the
Content-length header from the response is not rewritten, it is assumed to
be exact.
The transfer-encoding: chunked is removed, so sending a content-length
header is right.
The chunked body is de-chunked (so varnish knows the real Content-length),
and added in the new de-chunked response body without altering the initial
Content-Length header.
If this content length is wrong, the de-chunked content could contain a
second http response (http smuggling).
Expected behavior:
-------------------
Either:
* close the connection in error in case of conflict between the observed
Content-Length and the original Content-Length
* or fix the Content-length header if the length is known
* or reject backend responses containing both chunked Transfer-Encoding
and Content-Length
There may be other problems with streamed responses, where chunks are
transferred as they come (not sure this is supported in varnish).
* if the Content-length header is not rejected, received chunks size
should not exceed the initial content-length (and then close client
connection if it happens)
* prevent content-length header in chunk trailers (do not forward it)
--
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1729>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator
_______________________________________________
varnish-bugs mailing list
varnish-bugs@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-bugs
and Content-length
----------------------+----------------------
Reporter: regilero | Type: defect
Status: new | Priority: normal
Milestone: | Component: varnishd
Version: 4.0.3 | Severity: normal
Keywords: |
----------------------+----------------------
RFC 7230:
> A sender MUST NOT send a Content-Length header field in any message
> that contains a Transfer-Encoding header field.
> (...)
So having a backend response with both headers is an issue on the backend
side.
It means this is not a security issue for varnish.
But when it happens:
RFC 7230:
> If a message is received with both a Transfer-Encoding and a
> Content-Length header field, the Transfer-Encoding overrides the
> Content-Length. Such a message might indicate an attempt to
> perform request smuggling (Section 9.5) or response splitting
> (Section 9.4) and ought to be handled as an error. A sender MUST
> remove the received Content-Length field prior to forwarding such
> a message downstream.
In varnish 4.0.3, maybe because of #1506 and https://www.varnish-
cache.org/trac/changeset/535d44b8909ee88e8700a35bed79f9ca77e445a4 the
Content-length header from the response is not rewritten, it is assumed to
be exact.
The transfer-encoding: chunked is removed, so sending a content-length
header is right.
The chunked body is de-chunked (so varnish knows the real Content-length),
and added in the new de-chunked response body without altering the initial
Content-Length header.
If this content length is wrong, the de-chunked content could contain a
second http response (http smuggling).
Expected behavior:
-------------------
Either:
* close the connection in error in case of conflict between the observed
Content-Length and the original Content-Length
* or fix the Content-length header if the length is known
* or reject backend responses containing both chunked Transfer-Encoding
and Content-Length
There may be other problems with streamed responses, where chunks are
transferred as they come (not sure this is supported in varnish).
* if the Content-length header is not rejected, received chunks size
should not exceed the initial content-length (and then close client
connection if it happens)
* prevent content-length header in chunk trailers (do not forward it)
--
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1729>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator
_______________________________________________
varnish-bugs mailing list
varnish-bugs@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-bugs