VSV00007 Varnish HTTP/2 Request Smuggling Attack
================================================
Date: 2021-07-13
A request smuggling attack can be performed on Varnish Cache and Varnish
Cache Plus servers that have the HTTP/2 protocol enabled. The smuggled
requests do not go through normal VCL processing, and any authorisation
steps implemented in VCL would be bypassed.
The responses to the smuggled requests can under some circumstances also
be obtained by the attacker. Also, it may be possible for an attacker to
use this for cache poisoning, where the response to a smuggled request is
inserted as the cached content.
Identifying smuggled requests
-----------------------------
Smuggled requests will not show in any logs generated by Varnish, but
would show in the backend logs. It may be possible to identify the
smuggled requests in the backend logs by missing Varnish inserted
artifacts, like the `X-Varnish` header. Though a determined attacker may
spoof these artifacts in the smuggled requests.
Versions affected
-----------------
* Varnish Cache releases 6.0.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, 6.0.5, 6.1.0,
6.1.1, 6.2.0, 6.2.1, 6.2.2, 6.2.3, 6.3.0, 6.3.1, 6.3.2, 6.4.0, 6.5.0,
6.5.1, 6.6.0.
* Varnish Cache releases 5.x.x. Notice that the experimental HTTP/2
support in these releases are known to have several issues, and enabling
HTTP/2 is not recommended.
* Varnish Cache 6.0 LTS by Varnish Software up to and including 6.0.7
Versions not affected
---------------------
* All versions of Varnish Cache prior to version 5.0.0
Fixed in
--------
* Varnish Cache 6.6.1
* Varnish Cache 6.5.2
* Varnish Cache 6.0 LTS version 6.0.8
* GitHub Varnish Cache master branch at commit
450961a019d1c1955ca1851d51940ff2c87bdc98
Mitigation
----------
Mitigation is possible by either disabling the HTTP/2 protocol, or
preventing backend connection reuse.
Turning off support for HTTP/2:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The problem only affects servers that have HTTP/2 support enabled. This
support can be turned off at runtime. To disable HTTP/2 on a server do::
sudo varnishadm param.set feature -http2
To verify that HTTP/2 is disabled on a server, execute this command and
make sure the current value does not list `http2`::
sudo varnishadm param.show feature
When using Hitch (or any other TLS termination proxy) in front of Varnish
to handle TLS termination, you should also unlist the `h2` token as a
possible protocol in the ALPN advertisement sent to connecting clients.
To unlist `h2` as a supported protocol in Hitch, remove or comment out the
line stating `alpn-protos = "h2, http/1.1"` in your Hitch configuration
file. Then restart the Hitch service (reload is not sufficient).
Preventing connection reuse
~~~~~~~~~~~~~~~~~~~~~~~~~~~
On compliant backends it is possible to prevent the execution of smuggled
requests by disabling connection reuse of backend requests. Note that for
this workaround to be effective, it relies on the backend to refuse any
additional requests after seeing a `Connection: close` header.
To disable backend connection reuse, add a `Connection: close` header on
the outgoing backend requests::
sub vcl_backend_fetch {
set bereq.http.Connection = "close";
}
Credits
-------
Martin Blix Grydeland at Varnish Software for identifying and handling the
issue.
================================================
Date: 2021-07-13
A request smuggling attack can be performed on Varnish Cache and Varnish
Cache Plus servers that have the HTTP/2 protocol enabled. The smuggled
requests do not go through normal VCL processing, and any authorisation
steps implemented in VCL would be bypassed.
The responses to the smuggled requests can under some circumstances also
be obtained by the attacker. Also, it may be possible for an attacker to
use this for cache poisoning, where the response to a smuggled request is
inserted as the cached content.
Identifying smuggled requests
-----------------------------
Smuggled requests will not show in any logs generated by Varnish, but
would show in the backend logs. It may be possible to identify the
smuggled requests in the backend logs by missing Varnish inserted
artifacts, like the `X-Varnish` header. Though a determined attacker may
spoof these artifacts in the smuggled requests.
Versions affected
-----------------
* Varnish Cache releases 6.0.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, 6.0.5, 6.1.0,
6.1.1, 6.2.0, 6.2.1, 6.2.2, 6.2.3, 6.3.0, 6.3.1, 6.3.2, 6.4.0, 6.5.0,
6.5.1, 6.6.0.
* Varnish Cache releases 5.x.x. Notice that the experimental HTTP/2
support in these releases are known to have several issues, and enabling
HTTP/2 is not recommended.
* Varnish Cache 6.0 LTS by Varnish Software up to and including 6.0.7
Versions not affected
---------------------
* All versions of Varnish Cache prior to version 5.0.0
Fixed in
--------
* Varnish Cache 6.6.1
* Varnish Cache 6.5.2
* Varnish Cache 6.0 LTS version 6.0.8
* GitHub Varnish Cache master branch at commit
450961a019d1c1955ca1851d51940ff2c87bdc98
Mitigation
----------
Mitigation is possible by either disabling the HTTP/2 protocol, or
preventing backend connection reuse.
Turning off support for HTTP/2:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The problem only affects servers that have HTTP/2 support enabled. This
support can be turned off at runtime. To disable HTTP/2 on a server do::
sudo varnishadm param.set feature -http2
To verify that HTTP/2 is disabled on a server, execute this command and
make sure the current value does not list `http2`::
sudo varnishadm param.show feature
When using Hitch (or any other TLS termination proxy) in front of Varnish
to handle TLS termination, you should also unlist the `h2` token as a
possible protocol in the ALPN advertisement sent to connecting clients.
To unlist `h2` as a supported protocol in Hitch, remove or comment out the
line stating `alpn-protos = "h2, http/1.1"` in your Hitch configuration
file. Then restart the Hitch service (reload is not sufficient).
Preventing connection reuse
~~~~~~~~~~~~~~~~~~~~~~~~~~~
On compliant backends it is possible to prevent the execution of smuggled
requests by disabling connection reuse of backend requests. Note that for
this workaround to be effective, it relies on the backend to refuse any
additional requests after seeing a `Connection: close` header.
To disable backend connection reuse, add a `Connection: close` header on
the outgoing backend requests::
sub vcl_backend_fetch {
set bereq.http.Connection = "close";
}
Credits
-------
Martin Blix Grydeland at Varnish Software for identifying and handling the
issue.