|
Message-Id: <201407081836.s68IaX7O002273@linus.mitre.org> Date: Tue, 8 Jul 2014 14:36:33 -0400 (EDT) From: cve-assign@...re.org To: phk@....freebsd.dk Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: Varnish - no CVE == bug regression -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > https://www.varnish-cache.org/docs/trunk/reference/varnishd.html > auto_restart > Units: bool > Default: on > Restart child process automatically if it dies. > https://www.varnish-cache.org/docs/trunk/reference/vcl.html > Backend definition > host (mandatory) > The host to be used. IP address or a hostname that resolves to a > single IP address. Is it a supported configuration if auto_restart is off, and this hostname is specified using a DNS domain name? It seems that, if an attacker is occasionally successful at DNS spoofing (or spoofing at another level) and can thus trigger even one use of a rogue backend server, there's a long-lived denial of service. This is a denial of service caused by a well-defined attack against an issue in the Varnish code (an issue with no CVE ID at present). (It's not an interesting case if the attacker controls the domain name or is regularly successful in spoofing. The attacker could then trigger long-term use of nonexistent backend servers: from the end user's perspective, this isn't much different from a disruption of Varnish itself. And, presumably, it's even worse because the attacker could instead decide to provide wrong content instead of no content.) > By definition Varnish must explicitly and implicitly trust the > backend HTTP server With many realistic network designs, there isn't 100% assurance that this trusted server is always the actual origin of network traffic that appears to be from this server, and has a malicious HTTP header. Thus, it seems that you are trusting data for which it's essentially impossible to know whether this data originated inside of your security boundary. Still, this may be the security policy that you want to have. In other words, maybe what you are offering is sustained operation only in the case of a network infrastructure that's 100% impervious to a spoofing attack that succeeds for an instant of time. If there shouldn't be CVE assignments, would it be possible to update your documentation so that "auto_restart off" is labeled as a known risk for long-lived DoS conditions? - -- 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) iQEcBAEBAgAGBQJTvDmrAAoJEKllVAevmvmsG2gH/jFi8ju4yGdwqEh6paEWUdWY Mu1VPqBOxVJFsAGovRiQsXOdUaKAn1kyEw5uMUbCJo4/Zo+N8MAcGfm+wNNNRit2 BeJCgE85O+OeluD67iyHazNRCkYgmtUboLdDpefs0BHGG0v+3cm3RU5WajLETL1B ChwQ6Kvxym3+/Cd+m92Ii6od5sAQDzh/5Cc0ypr4zaTU6hCR+qdaE7Wr2vG/yZe0 hGdRkS6AU1Wcg3p15JVLCoLvqwQefhPccvgISvX/Y7Wz0piOlN5ZzhgrmzJut1bX Davr3Sy60Yf70iiR1db5MMWxx0EiK1jdioeD07uOkTb3z3OTH7PM0IHGkc23m5o= =6UYy -----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.