Re: Varnish - no CVE == bug regression

[Marek Kroemeke <kroemeke () gmail com>]

Hi phk,

Thanks for a fast reply - much appreciated (even if I don't actually agree
with you).

I'm not entirely convinced that there is a trust relationship between the
cache and the backend in every single use case. The simplest example would
be a CDN provider, where single customer could potentially keep crashing
the CDN's caches with a simple php script that adds Vary: header. Or shared
hosting where single customer can keep crashing the cache that fronts more
then one site.

Best regards,
Marek


On Thu, Jul 3, 2014 at 7:09 AM, Poul-Henning Kamp <phk () phk freebsd dk>
wrote:

> > > Latest version of Varnish cache (4.0.1 https://www.varnish-cache.org/
> ) has
> > > the same DoS vulnerability that 3.x had (which was subsequently fixed in
> > > that branch).
>
> Official response of the Varnish Project:
> -----------------------------------------
>
> It is of course a mistake to have such a regressions and we'll fix
> that (and any other relevant bugs we become aware of).
>
> But this is not a DoS vulnerability, and a CVE is not warranted.
>
> Explanation:
> ------------
>
> Varnish is a server side cache, which speeds up delivery of HTTP
> objects coming from one or more backend HTTP servers (typically
> apache, ngnix etc.)
>
> By definition Varnish must explicitly and implicitly trust the
> backend HTTP server -- it is the only source of authority it has over
> the HTTP content.
>
> Therefore, if your backend is compromised, your Varnish will
> faithfully serve whatever bogus contents the attackers put on your
> homepage, so I really don't think that the attackers being able to
> force an automatic restart of the varnish in front of it, is what
> you should be worried about.
>
> Once you fix your backend, Varnish will work the same as always.
>
>
> Even deeper explanation:
> ------------------------
>
> Notice that all the reported issues causes assert failures ?
>
> About 10% of Varnish source code are asserts in one form or another,
> to make sure that Varnish does not operate on bogus data or violate
> invariants.
>
> There are many error situations so pathlogical that an assert is
> the only relevant error handling.  Adding a lot of code to handle
> an obscure error condition gracefully, means that you have a lot
> of code which never gets run and therefore may contain *real* bugs
> or vulnerabilities.
>
> Our goal is that you should never be able to cause an assert from
> the client side -- that we would consider a DoS attack -- and
> eventually we may set the same goal for the backend side.
>
> But given that we trust the backend ultimately, and that varnish
> and the backend are both controlled by the same HTTP content
> owner, that is not a particular high priority for us:  If your
> backend is that screwed, it doesn't really matter what Varnish does
> anyway.
>
> Also notice, that Varnish is designed to automatically restart after
> an assert, so very little, if any service disruption takes place
> as a result of these asserts.  These automatic restarts can be
> disabled if you prefer.
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk () FreeBSD ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.