VSV00001

R1/source/conf.py

@@ -47,7 +47,7 @@ master_doc = 'index'
 
 # General information about the project.
 project = u'Varnish Cache Project'
-copyright = u'2016, Poul-Henning Kamp'
+copyright = u'2016,2017, Poul-Henning Kamp'
 author = u'Poul-Henning Kamp'
 
 # The version info for the project you're documenting, acts as replacement for

R1/source/index.rst

@@ -8,6 +8,12 @@ Varnish HTTP Cache
 What is happening
 -----------------
 
+2017-08-02 - Security Advisory: Denial of Service
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+All varnish versions from 4.0.1 are vulnerable to a Denial of Service
+attack, please see :ref:`vsv00001`
+
 2017-06-28 - Maintenance release 4.1.7
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 

R1/source/security/VSV00001.rst

+.. _vsv00001:
+
+VSV00001 DoS vulnerability
+==========================
+
+CVE-<to be assigned, we couldn't get one under embargo>
+
+Date:	2017-08-02
+
+A wrong if statement in the varnishd source code means that
+particular invalid requests from the client can trigger an assert.
+
+This causes the varnishd worker process to abort and restart, loosing
+the cached contents in the process.
+
+An attacker can therefore crash the varnishd worker process on
+demand and effectively keep it from serving content - a Denial-of-Service
+attack.
+
+Mitigation is possible from VCL or by updating to a fixed version
+of Varnish Cache.
+
+Versions affected
+-----------------
+
+* 4.0.1 to 4.0.4
+* 4.1.0 to 4.1.7
+* 5.0.0
+* 5.1.0 to 5.1.2
+
+Users of the Varnish Cache Plus product
+from Varnish Software: See the email you received from V-S.
+
+Versions not affected
+---------------------
+
+* All releases up to and including 4.0.0
+
+Fixed in
+--------
+
+* 4.0.5 and forward
+* 4.1.8 and forward
+* 5.1.3 and forward
+
+Users of the Varnish Cache Plus product
+from Varnish Software: See the email you received from V-S.
+
+Mitigation from VCL
+-------------------
+
+Note that there are subtle differences on the VCL workarounds,
+depending on which version of Varnish you are running, make sure
+to use the right one.
+
+These VCL snippets work by failing all client requests which attempt
+to use `Transfer-encoding: chunked`.
+
+Normally browsers will not issue such requests, but we know there
+are cases where B2B applications, APIs and special webservices
+will use client requests with chunked encoding.
+
+You can use this command to see if you have client traffic with
+chunked encoding::
+
+	varnishlog -cq ReqHeader:Transfer-Encoding -i ReqMethod -i ReqURL
+
+If you need some requests with chunked encoding to work, you will
+have to write VCL code to white-list these clients based on IP/
+authentication/cookies or other criteria, and then only call the
+`exploit_workaround_xxx` function for the malicios clients.
+
+Varnish 4.0.x (and Varnish Cache Plus 4.0.x)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Set the `vcc_allow_inline` parameter to `true`, either by passing::
+
+	-pvcc_allow_inline_c=true
+
+on the command line or by issuing the CLI command::
+
+	param.set vcc_allow_inline_c true
+
+Then add this to the front of your VCL::
+	
+	sub exploit_workaround_4_0 {
+		# This needs to come before your vcl_recv function
+		# The following code is only valid for Varnish Cache and
+		# Varnish Cache Plus versions 4.0.x
+		if (req.http.transfer-encoding ~ "(?i)chunked") {
+			C{
+			struct dummy_req {
+				unsigned magic;
+				int restarts;
+				int esi_level;
+				int disable_esi;
+				char hash_ignore_busy;
+				char hash_always_miss;
+				void *sp;
+				void *wrk;
+				int req_step;
+				struct {
+					void *a;
+					void *b;
+				};
+				int req_body_status;
+			};
+			((struct dummy_req *)ctx->req)->req_body_status = 6;
+			}C
+
+			return (synth(503, "Bad request"));
+		}
+	}
+
+	sub vcl_recv {
+		# Call this early in your vcl_recv function
+		call exploit_workaround_4_0;
+	}
+
+
+Varnish 4.1.x and 5.0 (and Varnish Cache Plus 4.1.x)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Set the `vcc_allow_inline` parameter to `true`, either by passing::
+
+	-pvcc_allow_inline_c=true
+
+on the command line or by issuing the CLI command::
+
+	param.set vcc_allow_inline_c true
+
+Then add this to the front of your VCL::
+
+	sub exploit_workaround_4_1 {
+		# This needs to come before your vcl_recv function
+		# The following code is only valid for Varnish Cache and
+		# Varnish Cache Plus versions 4.1.x and 5.0.0
+		if (req.http.transfer-encoding ~ "(?i)chunked") {
+			C{
+			struct dummy_req {
+				unsigned magic;
+				int step;
+				int req_body_status;
+			};
+			((struct dummy_req *)ctx->req)->req_body_status = 5;
+			}C
+
+			return (synth(503, "Bad request"));
+		}
+	}
+
+	sub vcl_recv {
+		# Call this early in your vcl_recv function
+		call exploit_workaround_4_1;
+	}
+		
+
+Varnish 5.1.x
+~~~~~~~~~~~~~
+
+Add this to the front of your VCL::
+
+	sub vcl_recv {
+		if (req.http.transfer-encoding ~ "(?i)chunked") {
+			return (fail);
+		}
+	}
+
+Source code fix
+~~~~~~~~~~~~~~~
+
+The source code fix is this one-liner::
+
+			if (q == NULL || *q != '\0')
+				ERR("chunked header number syntax");
+			cl = (ssize_t)cll;
+	-               if((uintmax_t)cl != cll)
+	+               if (cl < 0 || (uintmax_t)cl != cll)
+				ERR("bogusly large chunk size");
+	 
+			*priv = cl;
+
+On varnish 4.0.x this change goes into `bin/varnishd/cache/cache_http1_proto.c`
+on anything later it goes into `bin/varnishd/http1/cache_http1_vfp.c`.
+
+Thankyous and credits
+~~~~~~~~~~~~~~~~~~~~~
+
+This issue was first noticed by StackPath.com, who contacted their vendor, 
+Varnish Software, who in turn notified the Varnish Cache project.
+
+Varnish Software staff did most of the heavy lifting, and Martin in particular
+gets a hat-tip for trawling the source-code for any similar issues.
+
+And yes, I apologize for writing that buggy line of code.
+
+*phk*
+
+PS: See also `Yah! A security issue - finally! <http://varnish-cache.org/docs/trunk/phk/VSV00001.html>`_

R1/source/security/index.rst

 Security, bugs & vulnerabilities
 ================================
 
-* Rev. 2016-04-11 *phk*
+* Rev. 2018-08-02 *phk*
+
+.. toctree::
+	:maxdepth: 1
+
+	VSV00001.rst
 
 We take security and quality *very* seriously in the Varnish project,
-and that is why we have not had any major security scares in the
-ten year lifetime of the project.
+and we are more than a little proud that it took eleven years before
+we had a major security issue.
 
 I have found a security hole
 ----------------------------
@@ -17,34 +22,50 @@ I want to hear about security vulnerabilities
 
 Subscribe to the `Varnish Announce mailing list <https://www.varnish-cache.org/lists/mailman/listinfo/varnish-announce>`_
 
-Vulnerabilities are and will also be listed further down on this page.
+Vulnerabilities are and will also be listed further at the top of this page when they are new
+and further down when they get older.
+
+I'm a VIVU goddammit!
+---------------------
+
+Varnish users come in all sizes and importance, some are private
+homepages, some are global CDNs, national governments or major
+news outlets.
+
+We want to provide some way to for Varnish users to get early warning about
+future security incidents, but we do not want to pass judgement on
+who are "Very Important Varnish Users" and much less to we want to
+try to keep a list of up to date contact information for a list
+that long.
+
+We also don't want to make this information free, because if we
+did, every criminal and his brother would sign up, to get a head
+start against the Varnish users.
+
+The rule going forward is therefore that if you contributed at least
+EUR240 towards a `Varnish Moral License <http://phk.freebsd.dk/VML/>`_
+in the 12 months previous to the disclosure-date, you will get early
+warning about security issues.
+
+On a case-by-case basis and purely at our discretion, we will also
+extend this privilege to people who have contributed significantly
+to the project in other ways.
 
 Security Politics
 -----------------
 
-To be totally honest, this is section is rather speculative, but
-this is how I expect we would react to a major security issue:
+To be totally honest, this is section is quite speculative, we have
+very little experience in this area, but this is how I expect we
+would react to a major security issue:
 
-* Get a CVE assigned.
+* Assign a VSV number
+* Try to get a CVE assigned.
 * Create a VCL workaround, if at all possible.
 * Fix the problem.
 * If it makes sense (ie: no VCL workaround), roll a point-release.
 * Announce on announce@varnish-cache.org and homepage.
 * Kick ourselves, for *months*, for missing the bug.
 
-I'm a VIVU goddammit!
----------------------
-
-Varnish users come in all sizes and importance, some are private
-homepages, some are global CDNs, national governments or major
-news outlets.
-
-We do not have a formal structure in place to notify "Very Important
-Varnish Users", but we will try to give advance notice to them,
-if we know how to reach them.
-
-If you feel you are a VIVU, drop phk@ an email and tell him why.
-
 Define "Major"
 --------------
 
@@ -64,19 +85,20 @@ external contributors, which imperil Varnish users, we will not
 hesitate to issue a CVE to get peoples attention.
 
 
-10 years, really?
+11 years, really?
 -----------------
 
 Yes, indeed.  Luck probably has a lot to do with it, but luck tends
 to favour the well-prepared, and we have had a big focus on quality
 since the very start.
 
-`Here is a piece I wrote about it <https://r.varnish-cache.org/docs/trunk/phk/thatslow.html>`_
+`Here is a piece I wrote about it last year <https://r.varnish-cache.org/docs/trunk/phk/thatslow.html>`_
 
 
-List of Varnish CVEs
---------------------
+List of all Varnish security issues
+----------------------------------------
 
+* CVE-____-____ -- :ref:`vsv00001`
 * `CVE-2013-4484 -- < 3.0.5 -- DoS <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4484>`_
 * `CVE-2013-0345 -- <= 3.0.3 -- Local information leak <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0345>`_
 * `CVE-2009-4488 -- 2.0.6 -- Trophy hunting <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4488>`_
@@ -207,6 +229,3 @@ Poul-Henning Kamp, author and main developer of Varnish::
  =Bvkq
  -----END PGP PUBLIC KEY BLOCK-----
 
-.. toctree::
-	:hidden:
-