Determining whether VSV00008 affects 4.0.x

[Sylvain Beucler]

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 <beuc at beuc.net 
> <mailto:beuc at beuc.net>> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CVE-2022-23959.patch
Type: text/x-patch
Size: 782 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20220316/2b766077/attachment-0001.bin>
-------------- next part --------------
GET / HTTP/1.1
Host: localhost:6081
Content-Length: 25

GET /smug HTTP/1.0