Disclosure of sensitive information after registering openstack cloud provider

[dikonoor]

Password used for registering OpenStack Cloud Provider displayed in the evm.log. This is a security exposure and might be present in the older releases of ManageIQ as well and 'might' in all likelihood need a public CVE (common Vulnerability Evaluation) as this would fall under 'Information Exposure'. The evm.log has a read all file permissions, which basically means that any user logged into the system where ManageIQ is installed will be able to retrieve credentials of the Cloud Provider user.

As ManageIQ requires the credentials of a user with admin role on OpenStack, this basically implies that a hacker can grab the credentials, log into OpenStack and do just anything with the underlying infrastructure.

Even though this was found while registering OpenStack Cloud Provider, it is possible that this exposure exists for all other supported cloud providers. This needs to be verified. As I don't use other cloud providers, I will not be able to verify this.

Environment Details ManageIQ Release - Gaprinshdanvili (Beta) OpenStack Pike

Steps to Reproduce

1. Register a new OpenStack Cloud Provider to Manage IQ.
2. Credentials are valid and registration is successful.
3. Wait for few minutes and check the log and you should find the following:

[----] I, [2017-12-06T22:56:41.069274 #89849:fb10d0] INFO -- : MIQ(MiqQueue#m_callback) Message id: [96433], Invoking Callback with args: ["Finished", "ok", "Message delivered successfully", "#<Fog::Compute::OpenStack::Real:155741740 @openstack_auth_url=\"https://x.x.x.x:5000/v3/auth/tokens\" @openstack_username=\"user1\" @openstack_api_key=\"foobar123\"

@openstack_endpoint_type=\"publicURL\" @openstack_tenant=\"abc-default\" @openstack_project_name=\"abc-default\" @openstack_project_domain_id=\"default\" @openstack_user_domain_id=\"default\" @openstack_region=\"RegionOne\" @auth_token=\"gAAAAABaKLv5h3mHgv0YGGrZPYueqhedGQ8nvwMPJo80hHs2-pQinCPKE6ebPppKAnwwHn-nA1zmPzhEONMQXj_cAW6AbQ7yKWfzCmi51TGLc_U8o..."]

4. Please note that foobar123 is the password for user1 that I had used for registration.

Apart from just the credentials, the above log statement disclosures a lot of other information about the OpenStack provider..For eg. the project and domain scope, which enables a hacker to very easily generate a token and start using it on that OpenStack instance.

[martinpovolny]

Ping @aufi, @tzumainn

[aufi]

Hi, thanks for reporting. Could you check if you have enabled debug mode?

[dikonoor]

@aufi I don't see any DEBUG logging in my evm.log and I haven't changed any settings after following instructions to setup ManageIQ from here >> http://manageiq.org/docs/guides/developer_setup.html

Could you let me know how can I check if DEBUG logging is enabled?

[aufi]

Logging level can be configured in right top corner Configuration, then on the bottom of the page section Logging.

[dikonoor]

@aufi Got it..It's set to INFO

[aufi]

@dikonoor OK, thanks. We'll investigate and evaluate the issue accordingly.

[Fryguy]

@aufi @martinpovolny At a minimum we shouldn't even be putting an openstack (fog) object on the queue directly anyway, so maybe the fix is as simple as just removing it from the queue.

[aufi]

Agree on not putting objects to queue. The issue seems to be validate credentials action on Cloud Provider. Uses raw_connect method on ManagerMixin via MiqQueue. More detailed logs available at http://paste.openstack.org/show/tngptaORzGLBqT8gRsxA/

The method doesn't look to be used on other places, to it should be safe return true instead of connection object.

Previous changes related to this issue: https://github.com/ManageIQ/manageiq/pull/15606 and https://github.com/ManageIQ/manageiq-providers-openstack/pull/118/files#diff-6f9b687ce51fd31aa102fa9305ef2501R28

[ghost]

Why is the log file world readable? That in and of itself is typically going to result in a lot of CVE's, if we can tighten the permissions then even if sensitive data is logged it becomes a hardening problem and not a security vulnerability problem. If we can fix the log permissions that will largely deal with this in a quick manner, and prevent issues moving forwards.

[aufi]

The log files have same permissions as other product-related files on the appliance. @Fryguy can we get someone from appliance team to take a look on users priviledges and file permissions? Thanks.

[chargio]

Should a CVE be opened for this?

[Fryguy]

I don't think we need a CVE because this is not present in a released version of ManageIQ (except the Gaprindashvili Beta, but I don't believe we need CVEs for Betas)... @kseifriedredhat ?

[Fryguy]

@aufi I don't think this is an Openstack specific issue and might need a higher level fix as part of the work done to do credential validation via the queue. cc @jntullo

[ghost]

If this is in the Beta only and fixed prior to GA then yes, no CVE is needed. The general rule is CVE's are for released software, not alphas/betas, with some exceptions (like when Google Chrome was still in "beta" but had over 10 million users...).

[dikonoor]

Are we sure that this problem is not present in the previous releases? @aufi @kseifriedredhat

[Fryguy]

Fixed via https://github.com/ManageIQ/manageiq/pull/16636

@jntullo @aufi Can you just double check that this is not present on older versions? I'm pretty sure it's not as the verification-over-the-queue code was added for gaprindashvili, but it might be possible there were other providers going over the queue. Let's just double-check to be sure.