Hardcoded, weak, potentially unchangeable password in Cloudera plugin

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

just to add a little reference to this bug. i believe the credentials presented in the code are the default values for the service that is installed on this type of virtual machine image. to make this fully configurable we will need to synchronize the image creation with the requested password. alternatively perhaps there is a way for sahara to reset the password once an image is running, that would avoid creating new images to inject the password.

So just to move along this discussion a little bit, what is the impact of having hardcoded guessable credentials for this service?

What is this service used for? Are there any access controls on it? If a user logs in as administrator, what potentially damaging actions can they perform?

Travis, i will need to do some research about this specific application that is being installed but i believe it is a version of this[1]. having admin access will allow a user to control some of the functionality in the deployed cluster. i don't think it would allow access to any openstack services directly, but it may allow exploitation of the cluster nodes. i will followup with the cloudera folks.

in general, i think this may be a lower priority bug. i agree though that we should create a mechanism for allowing a customization of these values.

[1]: https://cloudera.com/content/cloudera/en/products-and-services/cloudera-enterprise/cloudera-manager.html

When was this added ? Is it a kilo feature ?

This specific part is being added as part of kilo, it is a piece of the Cloudera plugin version increase to v5.3.0.

We won't issue an advisory on this unles it makes it into the Kilo release, so it might be better to just make this bug public and expedite fixing before release.

Unless someone complains we will make this bug public Thursday.

/me agreed with Thierry

this review

https://review.openstack.org/#/c/165077/

is addressing this bug

I have one question: for we assume the cluster user will not use the password, why should we put it in configuration file? Can we generate the cloudera_manager password by uuid and store it in conductor db? I fact, currently the hive&sentry database passwords are generated by this method, in db_helper.py in cdh plugin. We may do the same thing for cloudera_manager password, and remove it from configuration file. I have already tried this method in my setup and it works. This also brings another advantage: each cluster can has its own admin password.

Ken, that would be another possible approach. if the user is never going to need that password then we could shift to a randomized password. will the end user ever need to login to the Cloudera Manager?

also, if we do move to a randomized password, will we need to add something that will set the password on the manager? my impression is that the current setting is the default for an installed Cloudera Manager and that to change that default the user would need to alter the image, is this accurate?

Michael, we do not need to change the image. The only thing is we need to change the password of CM user 'admin'. That can be done via cm_api update_user, like below style:
    api = get_api_client(cluster)
    user = api.get_user('admin')
    user.password = 'something'
    api.update_user(user)

thanks Ken, that is helpful. i'm still concerned about the extended implications of changing to a randomized password at this point in the process. i'm wondering if this approach will become a large enough change that we should create a spec for it and target for Liberty time frame.

Change abandoned by Michael McCune (<email address hidden>) on branch: master
Review: https://review.openstack.org/165077
Reason: Ken Chen is addressing this issue with a different approach that is more acceptable going forward.

Fix proposed to branch: master
Review: https://review.openstack.org/166279

Reviewed: https://review.openstack.org/166279
Committed: https://git.openstack.org/cgit/openstack/sahara/commit/?id=961d8ccd8e5ee1ddeb32ef9d84faeed694ec937e
Submitter: Jenkins
Branch: master

commit 961d8ccd8e5ee1ddeb32ef9d84faeed694ec937e
Author: Ken Chen <email address hidden>
Date: Fri Mar 20 23:17:25 2015 +0800

    Generate random password for CM admin user

    We use uuid to create and apply a random password for CM admin user.

    SecurityImpact

    Closes-Bug: #1429989
    Change-Id: Ie03f73cd07561f3ae7dcdbf97087b7a8e02417d1