<div dir="ltr"><font face="monospace">An assert can be triggered in Varnish Cache when using Varnish with a TLS<br>termination proxy, and the proxy and Varnish use the PROXY version 2<br>protocol to communicate connection details. Depending on the type of proxy<br>used and the details it include in the proxy payload, it may be possible<br>for remote clients to cause Varnish to assert and restart, making it a<br>denial of service attack.<br><br>The assert will cause Varnish to restart, and the cache will be empty<br>after the restart. This will reduce overall performance due to an<br>increased number of cache misses, and may cause higher load on the backend<br>servers.<br><br>There is no potential for remote code execution or data leaks related to<br>this vulnerability.<br><br>Mitigation is possible by configuration tuning, or by updating to a fixed<br>version of Varnish Cache.<br><br><br>Versions affected<br>-----------------<br><br>* Varnish Cache releases 6.0.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, 6.0.5, 6.1.0,<br>  6.1.1, 6.2.0, 6.2.1, 6.2.2, 6.3.0, 6.3.1.<br>* 6.0 LTS by Varnish Software up to and including 6.0.5<br><br>Fixed in<br>--------<br><br>* Varnish Cache 6.2.3<br>* Varnish Cache 6.3.2<br>* 6.0.6 LTS by Varnish Software<br>* GitHub Varnish Cache master branch at commit<br>  2d8fc1a784a1e26d78c30174923a2b14ee2ebf62<br><br><br>Mitigation<br>----------<br><br>It is possible to mitigate the problem in several ways.<br><br>Switch to proxy protocol version 1<br>""""""""""""""""""""""""""""""""""<br><br>Setups using proxy protocol version 1 are not affected, so if the TLS<br>termination proxy used supports both versions, switching to version 1 will<br>mitigate the problem. This is the recommended mitigation method.<br><br>Note that version 1 of the proxy protocol will communicate less details<br>about the connection than what is possible when using version 2. For<br>example the SNI server name used by the connecting client will not be<br>transferred, and can then not be queried using the Proxy VMOD in VCL.<br><br>When using the Hitch TLS proxy, version 1 of the proxy protocol can be<br>selected by replacing any ``write-proxy`` or ``write-proxy-v2`` options<br>with ``write-proxy-v1``, and restarting Hitch.<br><br><br>Disallow non-matching SNI names in Hitch<br>""""""""""""""""""""""""""""""""""""""""<br><br>When using Hitch as the TLS termination proxy, one can work around the<br>problem by disallowing client connects connecting using a SNI servername<br>that does not match any of the configured certificates. This can be done<br>by adding the ``sni-nomatch-abort`` option to the Hitch configuration.<br><br>Please note that this mitigation strategy is only effective if none of the<br>configured certificates allow wildcard domain names.<br><br>Increase the session workspace<br>""""""""""""""""""""""""""""""<br><br>By increasing the session workspace, one can make sure that an attacker<br>can not successfully exhaust the space available, thus not triggering the<br>assert. The size it needs to be set at depends on the TLS proxy in use,<br>and what fields it include in the proxy payload and how a remote client<br>can influence its contents.<br><br>By default the session workspace is set to 512 bytes. The session<br>workspace can be changed by setting the ``workspace_session`` Varnish<br>parameter, and restarting the Varnish daemon.<br><br>When using Hitch as the TLS proxy, setting the session workspace to 34k<br>will mitigate the problem completely. Add "-p workspace_session=34k" to<br>the `varnishd` command line to set this value.<br><br>Note that increasing the session workspace will increase the amount of<br>memory Varnish holds per connection, and you may want to decrease the<br>memory cache size to compensate.<br><br>Thankyous and credits<br>---------------------<br><br>Varnish Software for handling this security incident.<br><br><br>-- <br>Martin Blix Grydeland<br>Senior Developer | Varnish Software</font></div>