Mailing List Archive

Determining whether VSV00008 affects 4.0.x
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@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
Re: Determining whether VSV00008 affects 4.0.x [ In reply to ]
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@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@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
Re: Determining whether VSV00008 affects 4.0.x [ In reply to ]
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@beuc.net
> <mailto:beuc@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.