Hello Martin,
Thank you for your detailed answer.
Indeed I could reproduce the 'Connection:' behavior in 6.0.9 (unfixed,
"keep-alive") vs 6.0.10 (fixed, "close") using an undersized GET body,
mimicking the test case timeout:
$ nc -v localhost 6081 < req.txt
(req.txt attached)
However I noted that 4.0.x always sets 'Connection: close' (and does
close the connection) using this test, with or without my patch, unlike
3.0.7 or 4.1.11, so it seems there's a specific behavior for the whole
4.0.x branch.
(no actual request smuggling detected with this test though)
If you happen to have a reproducer for this vulnerability I'd be
grateful and perform more tests. Otherwise I'll probably abstain from
untestable patching and point users to the mitigation.
Cheers!
Sylvain
PS: for the record 3.0.7 and 4.0.x < 4.0.2 do set "Connection:
keep-alive" with f00008.vtc AFAICT
On 15/03/2022 11:18, Martin Blix Grydeland wrote:
I believe the reason that you are seeing the test case succeed on 4.0.x
regardless of if the fix for VSV00008 has been applied comes down to how
the test case is constructed. The test case makes the Varnish server
answer with a synthetic response (a response generated by VCL code
internal to the Varnish server, as opposed to backend generated
responses that Varnish normally delivers), because that is a convenient
way to trigger the relevant code paths. And in Varnish prior to version
4.1 I believe, Varnish would always close the client connection when
doing synthetic responses, meaning the test case always succeeds there.
Though synthetic responses are not the only way to trigger the
problematic code paths in Varnish. Any request handling that would end
up with Varnish wanting to read and discard the unused request body from
the client socket before starting a response delivery would be
susceptible to the bug. One way to test it could maybe be to use a GET
request with a request body on a URL that would result in a cache hit.
These would then I presume also open the vulnerability on 4.0.x, but
unfortunately a test case using this approach has not been constructed.
When working on this vulnerability, we did not test specifically any
Varnish versions prior to the supported releases, which stops at Varnish
6.0 LTS series as the oldest. Though code analysis suggests this
vulnerability to be present since the very first releases, as listed in
our vulnerability description.
Regards,
Martin Blix Grydeland
On Fri, 11 Mar 2022 at 17:59, Sylvain Beucler <[email protected]
<mailto:[email protected]>> wrote:
Hello,
I'm working on Debian security updates, and we're looking at fixing
VSV00008 for Debian jessie (varnish 4.0.2).
AFAICT this version is not affected by VSV00008. I'm posting my
findings
here in case this helps others distros or vendors.
The test case for this vulnerability (f00008.vtc) passes for 4.0.x
starting with 4.0.2.
(note: backporting the test case requires s/resp.reason/resp.msg/)
git-bissect shows that from:
https://github.com/varnishcache/varnish-cache/commit/d11d4419f3f9fa1d70e984f80c2078ea44e9e53c
<https://github.com/varnishcache/varnish-cache/commit/d11d4419f3f9fa1d70e984f80c2078ea44e9e53c>
(<4.0.2) "Deal with any remaining request body in cnt_synth"
until:
https://github.com/varnishcache/varnish-cache/commit/0c35ac8a7df799b53c31d8429206b928a9b9ca2b
<https://github.com/varnishcache/varnish-cache/commit/0c35ac8a7df799b53c31d8429206b928a9b9ca2b>
(<4.1.0-beta1) "Use the HTTP/1 VFP's for fetching the req.body"
varnish-cache does not set "connection: keep-alive", but sets
"connection: closes" as expected, which also matches the documentation
work-around for VSV00008.
Backporting VSV00008's fix for 4.0.2 does not appear to alter this
behavior.
So AFAICT we do not need to fix VSV00008 for 4.0.2 in Debian jessie.
If you think I'm mistaken I'd be grateful if you could let me know.
Origin: https://github.com/varnishcache/varnish-cache/commit/dcbe8b9ebf5b352e2534fc5645afa1d9747e9647
Index: varnish-4.0.2/bin/varnishd/cache/cache_http1_fsm.c
===================================================================
--- varnish-4.0.2.orig/bin/varnishd/cache/cache_http1_fsm.c
+++ varnish-4.0.2/bin/varnishd/cache/cache_http1_fsm.c
@@ -627,7 +627,10 @@ HTTP1_DiscardReqBody(struct req *req)
return(0);
if (req->req_body_status == REQ_BODY_TAKEN)
return(0);
- return(HTTP1_IterateReqBody(req, httpq_req_body_discard, NULL));
+ int ret = HTTP1_IterateReqBody(req, httpq_req_body_discard, NULL);
+ if (req->req_body_status == REQ_BODY_FAIL)
+ req->doclose = SC_RX_BODY;
+ return(ret);
}
/*----------------------------------------------------------------------
GET / HTTP/1.1
Host: localhost:6081
Content-Length: 25
GET /smug HTTP/1.0
_______________________________________________
varnish-misc mailing list
[email protected]
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
