Determining whether VSV00008 affects 4.0.x

[Martin Blix Grydeland]

Hello Sylvain,

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> 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
> (<4.0.2) "Deal with any remaining request body in cnt_synth"
> until:
>
> 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.
>
> Cheers!
> Sylvain Beucler
> Debian LTS Team
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>


-- 

[image: A picture containing night sky Description automatically generated]


Martin Blix Grydeland
Senior Engineer | Varnish Software Group
Cache Smarter, Store More, Deliver Faster
www.varnish-software.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20220315/fcafd6f2/attachment.html>