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.