Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 6 Jun 2011 19:03:25 +0200
From: Alvaro Lopez Ortega <>
To: Jamie Strandboge <>
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

Am I missing something?
Is there any idea/proposal on how to fix up the issue properly?


On Fri, Jun 3, 2011 at 6:01 PM, Jamie Strandboge <>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:
> 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="" 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] is a public mailing list for
>    people to collaborate on security vulnerabilities and coordinate
>    security updates.
> --
> Jamie Strandboge             |

Greetings, alo

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.