[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOurorZCjmrrw0MPhca=8+qjLKofrhdHsJuee5_=rCBv87SPbg@mail.gmail.com>
Date: Thu, 3 Jul 2014 07:38:12 +0100
From: Marek Kroemeke <kroemeke@...il.com>
To: Poul-Henning Kamp <phk@....freebsd.dk>
Cc: Solar Designer <solar@...nwall.com>, oss-security@...ts.openwall.com,
varnish-misc@...nish-cache.org
Subject: Re: Varnish - no CVE == bug regression
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@....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@...eBSD.ORG | TCP/IP since RFC 956
> FreeBSD committer | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
