Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 10 Mar 2015 14:21:26 -0400 (EDT)
Subject: Re: Varnish 4.0.3 heap-buffer-overflow while parsing backend server HTTP response.

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:

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 ]
Version: GnuPG v1.4.14 (SunOS)


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.