Summary
=======
Varnish Cache with certain configurations is vulnerable to a denial
of service attack.
Three lines of VCL code solves the problem.
This issue was discovered by Ilia Sharov, Yandex.
This has been assigned CVE-2013-4484.
Details
=======
If Varnish receives a certain illegal request, and the subroutine
'vcl_error{}' restarts the request, the varnishd worker process
will crash with an assert.
The varnishd management process will restart the worker process,
but there will be a brief interruption of service and the cache
will be emptied, causing more traffic to go to the backend.
We are releasing this advisory because restarting from vcl_error{}
is both fairly common and documented.
This is purely a denial of service vulnerability, there is no risk
of privilege escalation.
Proof of concept
================
Given a VCL with the effect of:
sub vcl_error {
return(restart);
}
and a malformed HTTP request like:
GET<SP><SP><SP><CR><NL>
Host:<SP>foo<CR><NL>
<CR><NL>
Varnish will assert and restart the child process.
(The precise number of spaces after GET is not magic.)
Cause
=====
A malformed request should never reach the VCL processing in Varnish
in the first place, but for historical reasons we used vcl_error{}
to deliver the error-response for some malformed requests.
In future versions of Varnish, (4.x, 3.0.5) a standard summary 400
response will be returned for all requests which cannot be parsed
correctly, without VCL involvement.
Workaround
==========
Insert this at the top of your VCL file:
sub vcl_error {
if (obj.status == 400 || obj.status == 413) {
return(deliver);
}
}
Or add this test at the top of your existing vcl_error{}.
Versions affected
=================
At least 2.0.x, 2.1.x, 3.0.x, possibly also older versions.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
