A data leak can be triggered in Varnish Cache by a remote client if
Varnish Cache is using the
file stevedore for synthetic error
objects and the backend does not respond properly or times out.
This was discovered and patched respectively by Carlo Cannas of Altervista.org and @shamger.
Potential impact is data leak and segmentation fault:
The data leaked will be an excerpt from the anonymously mapped memory of the varnishd process, limited upwards to 4k bytes and it will be present in the body of the synthesized error object created in place of the failed backend fetch.
Some requests will cause varnishd to segfault. This happens when the buffer overflow causes a read of unmapped memory.
Repeated attempts to fetch leaked memory will eventually produce a segmentation fault which can be detected by the administrator.
All of the following conditions are required to trigger the problem:
file stevedore must be configured using the
[<name>=]file,... option to
A synthetic object must be created in
happens e.g. when Varnish is unable to get a properly formatted HTTP
response from the backend, or if requested from VCL by doing
(Note: The problem also applies in the same way for uses of the
deprecated and unsupported stevedore
The solution is to upgrade Varnish to one of the versions where this issue has been resolved, and then ensure that Varnish is restarted.
Organizations that are not able to upgrade their Varnish environment
on short notice can switch from the
file stevedore to the
The stevedore to use is specified using the
-s option to the
# Existing configuration specifying file varnishd -s file,1G,/var/lib/varnish/varnish_storage.bin # New configuration specifying malloc varnishd -s malloc,1G
Please note that the malloc stevedore uses system memory, and the cache size should be adjusted accordingly.
This is configured in:
/etc/sysconfig/varnish.paramsin Redhat and derivatives.
/etc/default/varnishin Debian and derivatives.
The vulnerability may trigger a segmentation fault, which will appear in the system logs.
Varnish Software would like to thank Carlo Cannas of Altervista.org and @shamger for discovering and patching the vulnerability.