Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
H
homepage
Project
Project
Details
Activity
Releases
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Commits
Open sidebar
varnishcache
homepage
Commits
7814a7c9
Commit
7814a7c9
authored
Oct 01, 2019
by
Martin Blix Grydeland
Committed by
Pål Hermunn Johansen
Oct 21, 2019
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Add VSV00004
parent
fd3b5b80
Changes
2
Show whitespace changes
Inline
Side-by-side
Showing
2 changed files
with
98 additions
and
0 deletions
+98
-0
VSV00004.rst
R1/source/security/VSV00004.rst
+97
-0
index.rst
R1/source/security/index.rst
+1
-0
No files found.
R1/source/security/VSV00004.rst
0 → 100644
View file @
7814a7c9
.. _VSV00004:
Subject: VSV00004 Workspace information leak
VSV00004 Workspace information leak
===================================
Date: 2019-10-21
A bug has been discovered in Varnish Cache where we fail to clear a
pointer between the handling of one client requests and the next on the
same connection. This can under specific circumstances lead to information
being leaked from the connection workspace.
The impact is an information leak, limited to the data in the workspace
used for handling the connection. This will typically be data structures
and stale header data from previous requests on the same connection, but
could also be temporary headers set during processing of VCL.
For the leak to occur, Varnish needs to switch to synthetic handling due
to an internal error, in order to generate an error response to the client
request. Note that it will not be a problem when synthetic response
handling is reached explicitly through VCL statements.
The leaked data will be pre populated in the `resp.reason` variable on
entering `vcl_synth`, and will unless overridden show up in the response
field of the HTTP response sent.
The following error situations will cause Varnish to go directly to
synthetic handling for the current client request, and can cause data to
be leaked:
* Reaching max_restarts. There is a maximum limit on how many times the
VCL is allowed to do a `return(restart)`, and when this limit is reached
the request is forced to synthetic handling to send an error response.
* Requests initiating backend fetches, there is no grace candidate, and
the backend responds, but fails to send valid HTTP headers in return. In
this situation, specifically for the single request initiating the
backend fetch, the request is forced to synthetic handling to send an
error response.
* Attempting to switch to another VCL label after a restart. Switching to
another VCL is only allowed on the first run through `vcl_recv`, and
attempts to do it later will force the request to synthetic handling to
send an error response.
To successfully attack a vulnerable Varnish server, the system must either
be vulnerable from its VCL configuration (max restarts or erroneous VCL
switching), or the attacker must be able to cause backend response issues.
Mitigation is possible from VCL or by updating to a fixed version
of Varnish Cache.
Versions affected
-----------------
* 5.0 and forward
* 6.0 LTS by Varnish Software up to and including 6.0.4
Fixed in
--------
* 6.3.1
* 6.2.2
* 6.0.5 LTS by Varnish Software
* GitHub Varnish Cache master branch at commit bd7b3d6d47ccbb5e1747126f8e2a297f38e56b8c
Mitigation from VCL
-------------------
It is possible to mitigate the problem through VCL, by making sure that
the `resp.reason` field is overridden in the `vcl_synth` function. That
will update the stale pointer value to a known value, eliminating the
problem.
The following does this by setting `resp.status` to itself, updating
`resp.reason` to the generic value for that status code in the process::
sub vcl_synth {
# This line should be added last in vcl_synth,
# or just before any return statements
set resp.status = resp.status;
}
Thankyous and credits
---------------------
Trygve Tønnesland of VG/Schibsted for discovering the vulnerability, and
responsible disclosure.
Varnish Software for handling this security incident.
R1/source/security/index.rst
View file @
7814a7c9
...
@@ -32,6 +32,7 @@ Versions CVE What
...
@@ -32,6 +32,7 @@ Versions CVE What
:hidden:
:hidden:
:maxdepth: 1
:maxdepth: 1
VSV00004.rst
VSV00003.rst
VSV00003.rst
VSV00002.rst
VSV00002.rst
VSV00001.rst
VSV00001.rst
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment