[CKAN-Security] Fwd: Upcoming CKAN release -- Security patches?

David Read david.read at hackneyworkshop.com
Fri Jun 28 16:39:34 UTC 2019


Eric's recommendations seem good, with a caveat:

> 1) API keys should never be returned to other users.

I agree with this for the Web interface and API. But I guess the
reason we allowed the full user object to be returned is so that
objects can be transferred to another CKAN instance, or stored as a
backup, and the creds stay usable. Canada I think do this, keeping the
admin CKAN and public CKAN in sync, using the "ckanapi dump/load"
commands. It would be good to know if that is really needed. But maybe
the solution to that is to put into the context the options:
"include_apikey" (new) and "include_password_hash" (existing), so that
they are available to CLI commands and ckanapi.LocalCKAN but not
through the web interface or API (because XSS potential).

> 2) API keys should be displayed once when generated, and from then on never revealed. If someone needs a new key, it should be regenerated.
> 3) API keys should be stored in the database in a form similar to passwords, not in plaintext.

We could add a migration script which hashes the API keys.

He suggests "embargoed release". As far as I can tell that means
keeping the knowledge and the patch to only trusted partners / vendors
until the day of release. This is what we do that anyway. (I don't
think he means putting an announcement out that a "serious patch will
be released in 7 days at 10:00EST".)

I'm still not sure if we should have continue our policy of being
obscure about security issues when we release patches. I can see the
logic that CKAN sites are very tardy to apply the patches. But most
open source projects seem to take the opposite approach - are
vehemently transparent and highlight CVEs in their changelog. Is it
because security hole finders demand maximum credit? What am I missing
here?

Paying for someone to rectify this seems like exactly the sort of
thing the Stewards should fund. Could do with CommunityBridge setup
asap methinks.

Enough from me. You probably discussed this yesterday at the meeting already...

Dave

D

On Thu, 27 Jun 2019 at 07:58, Adrià Mercader <adria.mercader at okfn.org> wrote:
>
> ---------- Forwarded message ---------
> From: Eric Soroos <eric at derilinx.com>
> Date: Wed, 26 Jun 2019 at 13:02
> Subject: Re: Upcoming CKAN release -- Security patches?
> To: Adrià Mercader <adria.mercader at okfn.org>
>
>
> Adrià,
>
> Thanks for getting back to me.  Since the initial email went out, I've
> realized that this is perhaps a bit more dangerous than I realized.
>
> If someone can find an XSS vulnerability or CORS misconfiguration in a
> CKAN install, then this is the only additional step to a full
> compromise. I know that there's been one XSS bug in the past, and
> given the plugin landscape, I'm certain that there are others out
> there, even if CKAN core is fine.
>
> My experience in other open source communities is that this is a good
> candidate for an embargoed release, as it's trivially exploitable if
> someone has one other bug in their pocket. I realize that this is a
> hard issue to do in a point release, as it intentionally breaks some
> backwards compatibility, but having a patch and a plan is far
> preferable to not having a patch and having the security issue leak
> anyway.
>
> FWIW, this is the hotfix patch that I'm using, It appears to be good
> for my uses.  It fixes the basic leak, but doesn't go any farther.
>
> diff --git a/ckan/ckan/lib/dictization/model_dictize.py
> b/ckan/ckan/lib/dictization/model_dictize.py
> index 9acb150..44e1eda 100644
> --- a/ckan/ckan/lib/dictization/model_dictize.py
> +++ b/ckan/ckan/lib/dictization/model_dictize.py
> @@ -577,16 +577,11 @@ def user_dictize(user, context,
> include_password_hash=False):
>          result_dict['apikey'] = apikey
>
>
>
>      if requester == user.name:
> -        result_dict['apikey'] = apikey
>          result_dict['email'] = email
>
>
>
>      if authz.is_sysadmin(requester):
> -        result_dict['apikey'] = apikey
>          result_dict['email'] = email
>
>
>
> -        if include_password_hash:
> -            result_dict['password_hash'] = password_hash
> -
>      model = context['model']
>      session = model.Session
>
>
>
> diff --git a/ckan/ckanext/datapusher/logic/action.py
> b/ckan/ckanext/datapusher/logic/action.py
> index b530273..da6bf54 100644
> --- a/ckan/ckanext/datapusher/logic/action.py
> +++ b/ckan/ckanext/datapusher/logic/action.py
> @@ -64,6 +64,7 @@ def datapusher_submit(context, data_dict):
>      site_url = h.url_for('/', qualified=True)
>      callback_url = h.url_for('/api/3/action/datapusher_hook', qualified=True)
>
>
>
> +    context['keep_apikey'] = True
>      user = p.toolkit.get_action('user_show')(context, {'id': context['user']})
>
>
>
>      for plugin in p.PluginImplementations(interfaces.IDataPusher):
>
>
> eric
>
>
> On Jun 26, 2019, at 11:10 AM, Adrià Mercader <adria.mercader at okfn.org> wrote:
>
> Hi Eric,
>
> Thanks for reaching out, and many apologies that we didn't get back to
> you on your original email. I don't know what happened but we
> obviously failed to respond adequately.
>
> The upcoming patch releases doesn't contain any API key related
> changes. You raise some very valid points in your email and there have
> been discussions around API key management refactoring for a while but
> due to limited resources we haven't been able to work on that front.
> Perhaps your employer can help fund work on this?
>
> We can discuss the issue and come up with an implementation plan on
> the next dev meeting (https://hack.allmende.io/ckan-meeting#) You are
> more than welcome to join and discuss the issue with the tech team and
> others (meetings are open to everyone)
>
> Best,
>
>
> Adrià
>
> On Wed, 26 Jun 2019 at 11:51, Eric Soroos <eric at derilinx.com> wrote:
>
>
> Hi Adrià,
>
> I was wondering if you could tell me if the security issue that I
> raised on the security at ckan.org list on May 29 is going to be patched
> in the upcoming point releases?
>
> I haven't heard anything back from the CKAN org, and I'm worried about this one.
>
> Thanks
>
> eric
>
> Eric Soroos, Senior Developer
> Derilinx - Linked & Open Data Solutions
>
> Web: www.derilinx.com
> Email: eric at derilinx.com
> Address: 11/12 Baggot Court, Dublin 2, D02 F891
> Tel: +353 (0)1 254 4316
> Mob: +353 (0)83 8730257
> Twitter: @derilinx
>
>
> Eric Soroos, Senior Developer
> Derilinx - Linked & Open Data Solutions
>
> Web: www.derilinx.com
> Email: eric at derilinx.com
> Address: 11/12 Baggot Court, Dublin 2, D02 F891
> Tel: +353 (0)1 254 4316
> Mob: +353 (0)83 8730257
> Twitter: @derilinx
> _______________________________________________
> CKAN security
> https://lists.okfn.org/mailman/listinfo/security
> https://lists.okfn.org/mailman/options/security/david.read%40hackneyworkshop.com
>
> Repo: https://github.com/ckan/ckan-security



More information about the Security mailing list