[CKAN-Security] Security post from philip.ashlock at gsa.gov requires approval

Wed Jun 6 08:42:43 UTC 2018

Hi Philip,

Many thanks for reporting this.

I read some issues that seem to be related to this and I must admit
I'm still a bit unclear about how best to tackle it. Besides it looks
like it also depends on the exact setup of each instance as headers
can be set or sanitized by a proxy like Nginx.  A proof of concept or
steps to reproduce would be amazing if you could provide them.

https://github.com/pallets/werkzeug/issues/609
https://github.com/pallets/werkzeug/pull/1303

Thinking out loud, if this needs to be addressed at the CKAN level, we
could remove the X-Forwarded-Host HTTP header or make it match the
host defined in ckan.site_url, although I'm not sure if both these
approaches can have implications for sites running behind a proxy.

> we'd also appreciate assistance in bringing the disclosure to the attention of those developers.

Can you clarify what do  you mean by this?

Thanks again, please let us know if you can provide more details.

Adrià

On 6 June 2018 at 00:07,  <security-owner at lists.okfn.org> wrote:
> As list administrator, your authorization is requested for the
> following mailing list posting:
>
>     List:    Security at lists.okfn.org
>     From:    philip.ashlock at gsa.gov
>     Subject: X-Forwarded-Host HTTP header is always trusted and is used in url_for
>     Reason:  Post by non-member to a members-only list
>
> At your convenience, visit:
>
>     https://lists.okfn.org/mailman/admindb/security
>
> to approve or deny the request.
>
>
> ---------- Forwarded message ----------
> From: Philip Ashlock - QXA <philip.ashlock at gsa.gov>
> To: security at ckan.org
> Cc: John Jediny - XAAB <john.jediny at gsa.gov>, Hyon Kim - XI <hyon.kim at gsa.gov>
> Bcc:
> Date: Tue, 5 Jun 2018 18:06:37 -0400
> Subject: X-Forwarded-Host HTTP header is always trusted and is used in url_for
> Hello,
>
> Data.gov uses CKAN and is participating in a bug bounty program through hackerone.com. We are currently responding to a vulnerability that comes from libraries used by CKAN (specifically the url_for function provided by routes/flask). I haven't seen this reported with routes or flask, but my understanding is that routes is a port of the rails routing functionality and it does look like this vulnerability was reported under rails (also via HackerOne). You can see that vulnerability report here https://github.com/rails/rails/issues/29893
>
> If I understand correctly that this is a vulnerability impacting other CKAN instances and it is not something currently being addressed, we wanted to make sure it was brought to your attention. While I am aware that this appears to be caused by upstream libraries, I wanted to start by addressing it with CKAN, because the researcher who reported it to us on HackerOne has indicated they expect to publish their findings soon and include it in a talk at the Black Hat conference and they will likely use CKAN as an example.
>
> If you can confirm my understanding of this problem is correct and that it hasn't already been addressed or reported to the upstream libraries (routes/flask), we'd also appreciate assistance in bringing the disclosure to the attention of those developers.
>
> If you need more information or a proof of concept beyond the documentation reported with the issue on rails, we'd be happy to provide that.
>
> Best,
> Phil
>
>
>
>
> ---------- Forwarded message ----------
> From: security-request at lists.okfn.org
> To:
> Cc:
> Bcc:
> Date: Tue, 05 Jun 2018 22:07:06 +0000
> Subject: confirm 4a7cc0477df665a9a3805920adf086d5b81364a0
> If you reply to this message, keeping the Subject: header intact,
> Mailman will discard the held message.  Do this if the message is
> spam.  If you reply to this message and include an Approved: header
> with the list password in it, the message will be approved for posting
> to the list.  The Approved: header can also appear in the first line
> of the body of the reply.