oss-sec mailing list archives

Re: Security issue in cherokee

From: Alvaro Lopez Ortega <alvaro () octality com>
Date: Mon, 6 Jun 2011 19:03:25 +0200

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 () canonical 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 () lists 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/

Current thread:

Security issue in cherokee Jamie Strandboge (Jun 03)
- Re: Security issue in cherokee Alvaro Lopez Ortega (Jun 06)
- Re: Security issue in cherokee Josh Bressers (Jun 06)