[prev in list] [next in list] [prev in thread] [next in thread] 

List:       full-disclosure
Subject:    Re: [Full-disclosure] Medium security hole in Varnish reverse proxy
From:       Tim Brown <timb () nth-dimension ! org ! uk>
Date:       2010-03-29 23:04:15
Message-ID: 201003300004.32750.timb () nth-dimension ! org ! uk
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 29 March 2010 18:12:38 John Adams wrote:

> Post some code that people can evaluate.

I don't really like posting PoC code, but consider:

param.set user root
stop
start
vcl.inline test "backend default { .host = \"127.0.0.1\"; .port = \"8080\"; } 
C{ #include <aheaderfile.h> }C sub vcl_recv { C{ system(\"touch /tmp/foo\"); }C 
}"
vcl.use test

Should give you some ideas....

> For starters, There's no reason why varnish ever has to run as root.
> It never listens on privileged ports, and the C compiler is never
> available over a network interface.

The proxy process doesn't run as root by default, but that's not much 
consolation if the master process can reconfigure it at will.  The C compiler 
is available over whatever interface the master port is bound to, and in most 
cases that will be localhost:6082.  I've seen that as a default configuration 
for FreeBSD, Fedora, Debian and Ubuntu packages.

> You can ask varnish to reload a configuration and recompile it, but
> you'd have to have write access to the filesystem first.

Not strictly true, have a look at vcl.inline (as per the example above).

> You an also
> only cause recompilation to occur if the admin interface is up and
> running, which can be easily disabled.

True, but up until the latest version this was your only option since there 
was no authentication support and the default in many cases (including as 
noted in my advisory, the Redhat packaging files included in Varnish trunk) was 
to enable it.  The addition of authentication in 2.1.0 will /if enabled/ 
improve the situation no end.

> Poul is probably correct. Any vulnerabilities in Varnish with regards
> to privilege escalation are configuration issues.

Technically he is probably right but I still think the design sucks too, and 
let's be honest, an attacker probably doesn't need to make the distinction 
anyway.

Tim
-- 
Tim Brown
<mailto:timb@nth-dimension.org.uk>
<http://www.nth-dimension.org.uk/>

["signature.asc" (application/pgp-signature)]

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[prev in list] [next in list] [prev in thread] [next in thread]