Add vsv00008 information page

R1/source/security/VSV00008.rst

+.. _VSV00008:
+
+VSV00008 Varnish HTTP/1 Request Smuggling Vulnerability
+=======================================================
+
+Date: 2022-01-25
+
+A request smuggling attack can be performed on HTTP/1 connections on
+Varnish Cache servers. The smuggled request would be treated as an
+additional request by the Varnish server, go through normal VCL
+processing, and injected as a spurious response on the client connection.
+
+Identifying smuggled requests
+-----------------------------
+
+Smuggled requests will show in the logs generated by Varnish as normal
+requests. It may be possible to identify the smuggled requests by
+comparing the Varnish logs with logs from any proxy software between the
+Varnish server and the client.
+
+Versions affected
+-----------------
+
+* Varnish Cache releases 1.x, 2.x, 3.x, 4.x, 5.x, 6.0.x, 6.1.x, 6.2.x,
+  6.3.x, 6.4.x, 6.5.x, 6.6.0, 6.6.1, 7.0.0, 7.0.1.
+
+* Varnish Cache 6.0 LTS series up to and including 6.0.9.
+
+* All versions of Varnish Cache 4.1 LTS series.
+
+Versions not affected
+---------------------
+
+* Varnish Cache 6.6.2 (released 2022-01-25)
+
+* Varnish Cache 7.0.2 (released 2022-01-25)
+
+* Varnish Cache 6.0 LTS version 6.0.10 (released 2022-01-25)
+
+* GitHub Varnish Cache master branch at commit {TBD}
+
+Mitigation
+----------
+
+If upgrading Varnish is not possible, it is possible to mitigate the
+problem by ensuring that the Varnish Server does not allow connection
+reuse on HTTP/1 client connections.  Be advised that this comes with a
+performance penalty, and should for this reason only be considered as a
+temporary workaround in environments where this performance penalty is
+acceptable. To deploy the workaround, put the following VCL configuration
+towards the top of the VCL configuration::
+  
+  sub vcl_synth {
+      if (req.proto != "HTTP/2.0") {
+          set resp.http.Connection = "close";
+      }
+  }
+
+  sub vcl_deliver {
+      if (req.proto != "HTTP/2.0") {
+          set resp.http.Connection = "close";
+      }
+  }
+
+Credits
+-------
+
+This problem was discovered and reported to us by James Kettle, Director
+of Research at PortSwigger. We wish to thank him for the responsible
+disclosure.