[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150310182126.CDAF66C0079@smtpvmsrv1.mitre.org>
Date: Tue, 10 Mar 2015 14:21:26 -0400 (EDT)
From: cve-assign@...re.org
To: kroemeke@...il.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: Varnish 4.0.3 heap-buffer-overflow while parsing backend server HTTP response.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> Our understanding after previous reports is that varnish security model assumes full
> trust of the backend, so this is not considered a security problem
We'll try to infer CVE inclusion based on:
http://openwall.com/lists/oss-security/2014/07/08/13
Our understanding is that Varnish Cache trusts the backend HTTP
servers for two specific properties:
1. integrity of the web content
2. availability of the externally offered web service
In the July 2014 discussion, the scenario was that a single use of a
rogue backend server, caused by DNS spoofing, could cause a long-lived
denial of service of the externally offered web service. There wasn't
a CVE ID assignment because (as a rough summary) the product resolves
DNS names only once, and the administrator is able to verify the IP
addresses before those addresses are used.
More generally, no privilege boundary is crossed if a backend HTTP
server arbitrarily interferes with the intended behavior of the
externally offered web service.
There's a separate question of whether a privilege boundary is crossed
if a backend HTTP server can take control of the Varnish Cache server
machine. As far as we know, the Varnish Cache vendor has not directly
commented on that.
So, we expect that the outcome would be:
- if the AddressSanitizer report corresponds to a buffer overflow or
buffer over-read that we understand is exploitable only for a
crash, then there won't be a CVE
- if the AddressSanitizer report corresponds to a remote code
execution vulnerability, then it's up to the vendor to clarify
their perspective on trusting backend HTTP servers. If a system
administrator decides to use a DNS domain name in a backend
definition, and this results in reaching a wrong backend server,
and that backend server launches a successful code-execution
attack, this is perhaps sufficiently outside the bounds of
expected or reasonable behavior that a CVE is required.
- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJU/zWoAAoJEKllVAevmvmsEAIIAJXn5WTb28VWOJTx2rQTUNyf
rOAsm0IzgUYYDf0+061CwTzyZrNV3IjLYBs6P2/t+Qvh1Z9F2+sDcf1cWn7dJORo
6cc7m6hUBBaFBbYItDKp4UvnBMiyEKeC3bMEnMPdB6Z/Ukev2tO8Go6RwJL0jnDP
Ry48HSNhiJMtBmMf+PXsq4rOFz3VSvJhL0iv105URg/h8hBM0WZqhjfVL0MGuGDu
jdvlz3GR3xl7rPgaPDsKN/jdVcDVkKKvsbjD6yeJ6G28WuSg29VRDVQZX+utm5LE
MwNZzEyTqffDtSJzx1nieTczLK7wcg+bD8wmb6rwFYf/Tsy0OZGOdyf6vaJsTPU=
=tBwy
-----END PGP SIGNATURE-----
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.
