Mailing List Archive: Detecting and fixing VSV00004 in older releases

Detecting and fixing VSV00004 in older releases

Apr 18, 2020, 12:17 PM

Post #1 of 8 (1440 views)

Hi,

I'm part of the Debian LTS (Long Term Support) team, I'm checking what
Debian varnish packages are affected by CVE-2019-20637, and how to fix them.

In particular, we ship 4.0.2 and 5.0.0, where cache_req_fsm.c is too
different to apply the git patch with good confidence.

I appreciate that these versions are not officially supported anymore by
the Varnish project. Since it is common in GNU/Linux distros to provide
security fixes to users of packaged releases when feasible, I'm
classifying this vulnerability and looking for a fix.

Is there a patch for older Varnish releases, or failing that, a
proof-of-concept that would help me trigger and fix the vulnerability?

Note: to determine whether the versions are affected, and possibly
backport the patch, I tried to reproduce the issue following the
detailed advisory but without success, including on a vanilla 6.0.4:

/etc/vanish/default.vcl:
vcl 4.0;
backend default {
.host = "127.0.0.1";
.port = "80";
}
sub vcl_deliver {
if (req.url ~ "/2") {
set resp.status = 123;
set resp.reason = "blah";
return(restart);
}
}
sub vcl_synth {
synthetic( {"Status: "} + resp.status + {"
Reason: "} + resp.reason + {"
XID: "} + req.xid + {"
"} );
return (deliver);
}

./varnishd -F -a :6081 -f /etc/varnish/default.vcl -p max_restarts=1

curl localhost:6081/1 localhost:6081/2
-> Reason: Service Unavailable
(no leak)

Regards,
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: Detecting and fixing VSV00004 in older releases [ In reply to ]

dridi at varni

Apr 22, 2020, 10:40 PM

Post #2 of 8 (1435 views)

Permalink

Bonjour Sylvain,

On Sat, Apr 18, 2020 at 7:18 PM Sylvain Beucler <beuc@beuc.net> wrote:
>
> Hi,
>
> I'm part of the Debian LTS (Long Term Support) team, I'm checking what
> Debian varnish packages are affected by CVE-2019-20637, and how to fix them.
>
> In particular, we ship 4.0.2 and 5.0.0, where cache_req_fsm.c is too
> different to apply the git patch with good confidence.
>
> I appreciate that these versions are not officially supported anymore by
> the Varnish project. Since it is common in GNU/Linux distros to provide
> security fixes to users of packaged releases when feasible, I'm
> classifying this vulnerability and looking for a fix.

EOL series are definitely not a priority and I have other things to
look at before I can dive into this. So I will eventually revisit this
thread, or maybe someone will beat me to it if you're lucky.

> Is there a patch for older Varnish releases, or failing that, a
> proof-of-concept that would help me trigger and fix the vulnerability?

Not that I'm aware of.

> Note: to determine whether the versions are affected, and possibly
> backport the patch, I tried to reproduce the issue following the
> detailed advisory but without success, including on a vanilla 6.0.4:

If the advisory is inaccurate we will definitely want to amend it.

Dridi
_______________________________________________
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc

Re: Detecting and fixing VSV00004 in older releases [ In reply to ]

beuc at beuc

Apr 24, 2020, 4:23 AM

Post #3 of 8 (1433 views)

Permalink

Hi,

On 23/04/2020 07:40, Dridi Boukelmoune wrote:
> On Sat, Apr 18, 2020 at 7:18 PM Sylvain Beucler <beuc@beuc.net> wrote:
>> I'm part of the Debian LTS (Long Term Support) team, I'm checking what
>> Debian varnish packages are affected by CVE-2019-20637, and how to fix them.
>>
>> In particular, we ship 4.0.2 and 5.0.0, where cache_req_fsm.c is too
>> different to apply the git patch with good confidence.
>>
>> I appreciate that these versions are not officially supported anymore by
>> the Varnish project. Since it is common in GNU/Linux distros to provide
>> security fixes to users of packaged releases when feasible, I'm
>> classifying this vulnerability and looking for a fix.
>
> EOL series are definitely not a priority and I have other things to
> look at before I can dive into this. So I will eventually revisit this
> thread, or maybe someone will beat me to it if you're lucky.
>
>> Is there a patch for older Varnish releases, or failing that, a
>> proof-of-concept that would help me trigger and fix the vulnerability?
>
> Not that I'm aware of.
>
>> Note: to determine whether the versions are affected, and possibly
>> backport the patch, I tried to reproduce the issue following the
>> detailed advisory but without success, including on a vanilla 6.0.4:
>
> If the advisory is inaccurate we will definitely want to amend it.

Thanks for your answer.

Do we know in what version Trygve Tønnesland triggered the vulnerability?

Regards,
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: Detecting and fixing VSV00004 in older releases [ In reply to ]

beuc at beuc

May 6, 2020, 4:41 AM

Post #4 of 8 (1408 views)

Permalink

Hi,

On 24/04/2020 13:23, Sylvain Beucler wrote:
> On 23/04/2020 07:40, Dridi Boukelmoune wrote:
>> On Sat, Apr 18, 2020 at 7:18 PM Sylvain Beucler <beuc@beuc.net> wrote:
>>> I'm part of the Debian LTS (Long Term Support) team, I'm checking what
>>> Debian varnish packages are affected by CVE-2019-20637, and how to fix them.
>>>
>>> In particular, we ship 4.0.2 and 5.0.0, where cache_req_fsm.c is too
>>> different to apply the git patch with good confidence.
>>>
>>> I appreciate that these versions are not officially supported anymore by
>>> the Varnish project. Since it is common in GNU/Linux distros to provide
>>> security fixes to users of packaged releases when feasible, I'm
>>> classifying this vulnerability and looking for a fix.
>>
>> EOL series are definitely not a priority and I have other things to
>> look at before I can dive into this. So I will eventually revisit this
>> thread, or maybe someone will beat me to it if you're lucky.
>>
>>> Is there a patch for older Varnish releases, or failing that, a
>>> proof-of-concept that would help me trigger and fix the vulnerability?
>>
>> Not that I'm aware of.
>>
>>> Note: to determine whether the versions are affected, and possibly
>>> backport the patch, I tried to reproduce the issue following the
>>> detailed advisory but without success, including on a vanilla 6.0.4:
>>
>> If the advisory is inaccurate we will definitely want to amend it.
>
> Thanks for your answer.
>
> Do we know in what version Trygve Tønnesland triggered the vulnerability?

To put it differently, how would one make sure that applying
bd7b3d6d47ccbb5e1747126f8e2a297f38e56b8c fixes the issue in a Debian
version not explicitly referenced in VS0004, such as 6.1.1?

Regards,
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: Detecting and fixing VSV00004 in older releases [ In reply to ]

beuc at beuc

May 12, 2020, 9:27 AM

Post #5 of 8 (1398 views)

Permalink

Hi,

(adding security contact in Cc:)

On 06/05/2020 13:41, Sylvain Beucler wrote:
> On 24/04/2020 13:23, Sylvain Beucler wrote:
>> On 23/04/2020 07:40, Dridi Boukelmoune wrote:
>>> On Sat, Apr 18, 2020 at 7:18 PM Sylvain Beucler <beuc@beuc.net> wrote:
>>>> I'm part of the Debian LTS (Long Term Support) team, I'm checking what
>>>> Debian varnish packages are affected by CVE-2019-20637, and how to fix them.
>>>>
>>>> In particular, we ship 4.0.2 and 5.0.0, where cache_req_fsm.c is too
>>>> different to apply the git patch with good confidence.
>>>>
>>>> I appreciate that these versions are not officially supported anymore by
>>>> the Varnish project. Since it is common in GNU/Linux distros to provide
>>>> security fixes to users of packaged releases when feasible, I'm
>>>> classifying this vulnerability and looking for a fix.
>>>
>>> EOL series are definitely not a priority and I have other things to
>>> look at before I can dive into this. So I will eventually revisit this
>>> thread, or maybe someone will beat me to it if you're lucky.
>>>
>>>> Is there a patch for older Varnish releases, or failing that, a
>>>> proof-of-concept that would help me trigger and fix the vulnerability?
>>>
>>> Not that I'm aware of.
>>>
>>>> Note: to determine whether the versions are affected, and possibly
>>>> backport the patch, I tried to reproduce the issue following the
>>>> detailed advisory but without success, including on a vanilla 6.0.4:
>>>
>>> If the advisory is inaccurate we will definitely want to amend it.
>>
>> Thanks for your answer.
>>
>> Do we know in what version Trygve Tønnesland triggered the vulnerability?
>
> To put it differently, how would one make sure that applying
> bd7b3d6d47ccbb5e1747126f8e2a297f38e56b8c fixes the issue in a Debian
> version not explicitly referenced in VS0004, such as 6.1.1?

AFAICS no GNU/Linux distribution was able to fix their stable releases
so far.

We'd greatly appreciate information on reproducing the issue (such as
configuration file and curl request), to determine if our packages are
affected and whether we properly fixed them when attempting to backport
the fix. Cf. the start of the thread for my current attempt
https://varnish-cache.org/lists/pipermail/varnish-misc/2020-April/026854.html

In case you currently don't have the resources, would you mind
(privately) sharing the finder's contact with me so I can gather more
information?

Regards,
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: Detecting and fixing VSV00004 in older releases [ In reply to ]

dridi at varni

May 12, 2020, 10:00 AM

Post #6 of 8 (1398 views)

Permalink

Hello Sylvain,

<snip>

> >> Do we know in what version Trygve Tønnesland triggered the vulnerability?

It was first discovered on Varnish Enterprise, and once the origin of
the leak was identified we surveyed older and newer releases and fixed
the ones listed in the advisory.

> > To put it differently, how would one make sure that applying
> > bd7b3d6d47ccbb5e1747126f8e2a297f38e56b8c fixes the issue in a Debian
> > version not explicitly referenced in VS0004, such as 6.1.1?

I tried to reproduce it myself today and I wasn't able to trigger the
leak on the master branch's commit prior to the fix. I asked
internally whether we have a reliable reproducer or if it's something
that needs a consequential workload to be observable.

> AFAICS no GNU/Linux distribution was able to fix their stable releases
> so far.

That's not too bad, there is a workaround and it is overall a niche
case. If I remember correctly when it was brought to us it wasn't a
security problem for the reporter but we recognized the bug as such.

Please note that in 2 of the 3 scenarios your VCL is incorrect in the
first place, so you have other problems to deal with more pressing
than the information leak.

Dridi
_______________________________________________
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc

Re: Detecting and fixing VSV00004 in older releases [ In reply to ]

dridi at varni

May 13, 2020, 2:03 AM

Post #7 of 8 (1396 views)

Permalink

> I tried to reproduce it myself today and I wasn't able to trigger the
> leak on the master branch's commit prior to the fix. I asked
> internally whether we have a reliable reproducer or if it's something
> that needs a consequential workload to be observable.

The step I was missing trying to reproduce this on my own was ensuring
that the error reason is far enough in the client workspace to be
leakable.

It turns out we had a test case covering all 3 scenarios that was
supposed to be pushed a while after the disclosure, but was forgotten.

You can use this test case now before and after applying the patch:

https://github.com/varnishcache/varnish-cache/commit/0c9c38513bdb7730ac886eba7563f2d87894d734

Dridi
_______________________________________________
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc

Re: Detecting and fixing VSV00004 in older releases [ In reply to ]

beuc at beuc

May 13, 2020, 6:25 AM

Post #8 of 8 (1396 views)

Permalink

Hi,

On 13/05/2020 11:03, Dridi Boukelmoune wrote:
>> I tried to reproduce it myself today and I wasn't able to trigger the
>> leak on the master branch's commit prior to the fix. I asked
>> internally whether we have a reliable reproducer or if it's something
>> that needs a consequential workload to be observable.
>
> The step I was missing trying to reproduce this on my own was ensuring
> that the error reason is far enough in the client workspace to be
> leakable.
>
> It turns out we had a test case covering all 3 scenarios that was
> supposed to be pushed a while after the disclosure, but was forgotten.
>
> You can use this test case now before and after applying the patch:
>
> https://github.com/varnishcache/varnish-cache/commit/0c9c38513bdb7730ac886eba7563f2d87894d734

Thanks a lot!

I was able to check and fix one version (6.1.1), I'll now check the others.

Regards,
Sylvain Beucler
Debian LTS Team
_______________________________________________
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc