| Reporter | Title | Published | Views | Family All 46 |
|---|---|---|---|---|
| Medium: varnish | 14 Jan 201400:00 | – | amazon | |
| Amazon Linux AMI : varnish (ALAS-2014-276) | 5 Feb 201400:00 | – | nessus | |
| Debian DSA-2814-1 : varnish - denial of service | 10 Dec 201300:00 | – | nessus | |
| Fedora 20 : varnish-3.0.5-1.fc20 (2013-24018) | 6 May 201400:00 | – | nessus | |
| Fedora 19 : varnish-3.0.5-1.fc19 (2013-24023) | 6 May 201400:00 | – | nessus | |
| FreeBSD : varnish -- DoS vulnerability in Varnish HTTP cache (d9dbe6e8-84da-11e3-98bd-080027f2d077) | 27 Jan 201400:00 | – | nessus | |
| GLSA-201412-30 : Varnish: Multiple vulnerabilities | 16 Dec 201400:00 | – | nessus | |
| Mandriva Linux Security Advisory : varnish (MDVSA-2014:036) | 18 Feb 201400:00 | – | nessus | |
| openSUSE Security Update : varnish (openSUSE-SU-2013:1679-1) | 13 Jun 201400:00 | – | nessus | |
| openSUSE Security Update : varnish (openSUSE-SU-2013:1683-1) | 13 Jun 201400:00 | – | nessus |
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
[email protected] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
# 0day.today [2018-04-02] #Data
Build on a solid foundation with Vulners data
We provide the essential building blocks for cybersecurity solutions with comprehensive, structured, and constantly updated vulnerability and exploits data
Api
Power your application with Vulners API
The Vulners REST API offers reliable, high-performance access to vulnerability intelligence, with 99.9% SLA uptime and CDN-backed data delivery for seamless global access
App
Assess and manage vulnerabilities with Vulners tools
Built on top of Vulners' database and SDK, end-user solutions give security professionals and developers lightweight and powerful tools for vulnerability remediation