[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <79047.1404367766@critter.freebsd.dk>
Date: Thu, 03 Jul 2014 06:09:26 +0000
From: "Poul-Henning Kamp" <phk@....freebsd.dk>
To: Solar Designer <solar@...nwall.com>
cc: Marek Kroemeke <kroemeke@...il.com>, oss-security@...ts.openwall.com,
varnish-misc@...nish-cache.org
Subject: Re: Varnish - no CVE == bug regression
>> 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.
