the original cloud security

Varnish Cache Denial Of Service

Varnish Cache Denial Of Service
Posted Oct 31, 2013
Authored by Ilia Sharov

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. Versions 2.0.x, 2.1.x, and 3.0.x are affected.

tags | exploit, denial of service
advisories | CVE-2013-4484
MD5 | cb9615aec14bf539a5b30626f199edff

Varnish Cache Denial Of Service

Change Mirror Download


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.

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

February 2015

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Feb 1st
    2 Files
  • 2
    Feb 2nd
    17 Files
  • 3
    Feb 3rd
    15 Files
  • 4
    Feb 4th
    16 Files
  • 5
    Feb 5th
    14 Files
  • 6
    Feb 6th
    4 Files
  • 7
    Feb 7th
    0 Files
  • 8
    Feb 8th
    0 Files
  • 9
    Feb 9th
    0 Files
  • 10
    Feb 10th
    0 Files
  • 11
    Feb 11th
    0 Files
  • 12
    Feb 12th
    0 Files
  • 13
    Feb 13th
    0 Files
  • 14
    Feb 14th
    0 Files
  • 15
    Feb 15th
    0 Files
  • 16
    Feb 16th
    0 Files
  • 17
    Feb 17th
    0 Files
  • 18
    Feb 18th
    0 Files
  • 19
    Feb 19th
    0 Files
  • 20
    Feb 20th
    0 Files
  • 21
    Feb 21st
    0 Files
  • 22
    Feb 22nd
    0 Files
  • 23
    Feb 23rd
    0 Files
  • 24
    Feb 24th
    0 Files
  • 25
    Feb 25th
    0 Files
  • 26
    Feb 26th
    0 Files
  • 27
    Feb 27th
    0 Files
  • 28
    Feb 28th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2015 Packet Storm. All rights reserved.

close