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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ