<div dir="ltr"><font face="monospace">VSV00004 Workspace information leak<br>===================================<br><br>Date: 2019-10-21<br><br>A bug has been discovered in Varnish Cache where we fail to clear a<br>pointer between the handling of one client requests and the next on the<br>same connection. This can under specific circumstances lead to information<br>being leaked from the connection workspace.<br><br>The impact is an information leak, limited to the data in the workspace<br>used for handling the connection. This will typically be data structures<br>and stale header data from previous requests on the same connection, but<br>could also be temporary headers set during processing of VCL.<br><br>For the leak to occur, Varnish needs to switch to synthetic handling due<br>to an internal error, in order to generate an error response to the client<br>request. Note that it will not be a problem when synthetic response<br>handling is reached explicitly through VCL statements.<br><br>The leaked data will be pre populated in the `resp.reason` variable on<br>entering `vcl_synth`, and will unless overridden show up in the response<br>field of the HTTP response sent.<br><br>The following error situations will cause Varnish to go directly to<br>synthetic handling for the current client request, and can cause data to<br>be leaked:<br><br>* Reaching max_restarts. There is a maximum limit on how many times the<br>  VCL is allowed to do a `return(restart)`, and when this limit is reached<br>  the request is forced to synthetic handling to send an error response.<br><br>* Requests initiating backend fetches, there is no grace candidate, and<br>  the backend responds, but fails to send valid HTTP headers in return. In<br>  this situation, specifically for the single request initiating the<br>  backend fetch, the request is forced to synthetic handling to send an<br>  error response.<br><br>* Attempting to switch to another VCL label after a restart. Switching to<br>  another VCL is only allowed on the first run through `vcl_recv`, and<br>  attempts to do it later will force the request to synthetic handling to<br>  send an error response.<br><br>To successfully attack a vulnerable Varnish server, the system must either<br>be vulnerable from its VCL configuration (max restarts or erroneous VCL<br>switching), or the attacker must be able to cause backend response issues.<br><br>Mitigation is possible from VCL or by updating to a fixed version<br>of Varnish Cache.<br><br><br>Versions affected<br>-----------------<br><br>* 5.0 and forward<br>* 6.0 LTS by Varnish Software up to and including 6.0.4<br><br><br>Fixed in<br>--------<br><br>* 6.3.1<br>* 6.2.2<br>* 6.0.5 LTS by Varnish Software<br>* GitHub Varnish Cache master branch at commit </font>bd7b3d6d47ccbb5e1747126f8e2a297f38e56b8c<font face="monospace"><br><br><br>Mitigation from VCL<br>-------------------<br><br>It is possible to mitigate the problem through VCL, by making sure that<br>the `resp.reason` field is overridden in the `vcl_synth` function. That<br>will update the stale pointer value to a known value, eliminating the<br>problem.<br><br>The following does this by setting `resp.status` to itself, updating<br>`resp.reason` to the generic value for that status code in the process::<br><br>sub vcl_synth {<br>   # This line should be added last in vcl_synth,<br>   # or just before any return statements<br>   set resp.status = resp.status;<br>}<br><br><br>Thankyous and credits<br>---------------------<br><br>Trygve Tønnesland of VG/Schibsted for discovering the vulnerability, and<br>responsible disclosure.<br><br>Varnish Software for handling this security incident.</font><br><div><font face="monospace"><br></font></div><div><font face="monospace">Regards,</font></div><div><font face="monospace">Martin Blix Grydeland</font></div></div>