Re: Varnish - no CVE == bug regression

[Seth Arnold <seth.arnold () canonical com>]

On Thu, Jul 03, 2014 at 05:21:59PM -0600, Kurt Seifried wrote:
> In this case it's pretty simple: the back end web servers are NOT
> supposed to be able to shut down the varnish cache server (if this was
> supposed to happen you'd have built a proper channel to do so). That
> they can do so means it is a denial of service, and therefore a trust
> boundary violation. Ergo it needs a CVE.

I disagree; I don't think a CVE is warranted.

The developers have given us a clear and concise threat model that they
use for Varnish. It is simple, it is self-consistent, and best of all
it tells system administrators how they can safely use Varnish.

I think the OpenSSL ciphers is a poor analogy. A better analogy is PHP.
(My apologies to the Varnish developers, this is in no way meant to
equate Varnish with PHP. But stick with me...) The PHP interpreter is
not safe against malicious scripts. The mod_php implementation is not
safe for use if the PHP script authors are not as trusted as the Apache
authors. mod_php is not safe to use with multiple script authors. The
"safe_open" and similar functions are not security boundaries because
the scripts are completely trusted by design.

The HTTP backends behind Varnish are similar. If you have backend servers
in different trust domains, you get to run multiple Varnish front ends. If
you don't trust your HTTP servers, putting Varnish in front doesn't make
them suddenly safe.

If we start assigning CVEs for unexpected behaviour regardless of a
threat model we'll drive ourselves to insanity.

The Varnish team gave us a clear and concise vision of what they consider
trusted and untrusted. I am thankful they've thought it through and came
up with something reasonable. It might not be the threat model you would
have chosen -- which means it may not be the right tool for you.

Thanks

Attachment: signature.asc
Description: Digital signature