Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 3 Jul 2014 07:38:12 +0100
From: Marek Kroemeke <>
To: Poul-Henning Kamp <>
Cc: Solar Designer <>,,
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,

On Thu, Jul 3, 2014 at 7:09 AM, Poul-Henning Kamp <>

> >> Latest version of Varnish cache (4.0.1
> ) 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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ