sensitive "adminPass" information is logged in OpenStack service logs

[Dinesh Bhor]

If any OpenStack service calls nova "evacuate" or "rescue" API's the sensitive "adminPass" is logged in respective caller's service logs.

For example:

Masakari calls nova "evacuate" with nova api_version 2.9 [1][2] so the response body containing "adminPass" gets logged in masakari-engine logs through keystoneauth library [3] in _http_log_response() method.

nova "evacuate" API has been modified in api_version 2.14 [4] in which "adminPass" attribute is removed from response but previous versions will still log this sensitive information.

Nova "rescue" API returns "adminPass" with current nova api_version (2.46).

masakari-engine logs:

DEBUG novaclient.v2.client [req-c7be46e6-0369-43db-8da3-6792ad3b91a5 service None] RESP: [200] Content-Length: 29 Content-Type: application/json Openstack-Api-Version: compute 2.9 X-Openstack-Nova-Api-Version: 2.9 Vary: OpenStack-API-Version, X-OpenStack-Nova-API-Version X-Openstack-Request-Id: req-b0ea79ff-7bd6-472f-a2ae-c820758f39fb X-Compute-Request-Id: req-b0ea79ff-7bd6-472f-a2ae-c820758f39fb Date: Tue, 27 Jun 2017 09:42:21 GMT Connection: keep-alive
RESP BODY: {"adminPass": "8NchJ63X6tJh"}

The "adminPass" needs to be masked in keystoneauth at below location [5] using oslo_utils mask_password [6] where it logs the response body.

[1] https://github.com/openstack/masakari/blob/master/masakari/compute/nova.py#L42
[2] https://github.com/openstack/masakari/blob/master/masakari/compute/nova.py#L166-L174
[3] https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/session.py#L361
[4] https://docs.openstack.org/developer/nova/api_microversion_history.html#id12
[5] https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/session.py#L406
[6] https://github.com/openstack/oslo.utils/blob/master/oslo_utils/strutils.py#L248

[Jeremy Stanley (fungi)]

Reports of suspected vulnerabilities for keystoneauth are not overseen by the OpenStack VMT, but I'm taking the initiative to subscribe keystone-coresec reviewers to this bug anyway since it seems like it may have gone unnoticed (the reporter reached out to the VMT by E-mail to give us a heads up about this particular report).

My recommendation is for keystone-coresec to treat this as a security hardening opportunity since it only seems to affecr debug logging (class B3 in the VMT's report taxonomy), switch the bug type from Private Security to Public, and add the "security" bug tag to it comes to the attention of interested subscribers in the community.

[Morgan Fainberg (mdrnstm)]

Let me weigh in here.

1) I agree with Jeremy on the class of bug, it is clearly a hardening situation. This can be moved to public in my opinion.

2) The fix cannot be implemented as is. Keystoneauth cannot grow a dependency on any oslo libraries. There should (if anything) be a clear way to hand a logger to keystoneauth's session that can obscure the required information. Keystoneauth itself cannot know every value to sanitize. it is 100% acceptable to have the consumers pass an oslo-based-sanitizer to the keystoneauth session.

The reason for preventing the inclusion of any oslo libaries is that keystoneauth is meant to be a very low-level library that has minimal dependencies. This is to allow for greater inclusion (there are many cases where oslo libraries bring in huge dependency chains) without concern of ever-growing transient dependencies. In short, we work hard to ensure there are no new dependencies to keystoneauth without a significant vetting and consideration to the downstream consumers of keystoneauth.

I would be OK with a more direct implementation of generic sanitize hook that could be directly used on session (allowing any sanitizing to occur).

[Lance Bragstad (lbragstad)]

I agree with both the comments made by Jeremy and Morgan. I also find the Morgan's approach appropriate as a fix in order to keep keystoneauth's dependencies to a minimum.

[Morgan Fainberg (mdrnstm)]

This is also a duplicate of #1638978, since it is debug logs that are seen.

[Morgan Fainberg (mdrnstm)]

This has been made public via https://review.openstack.org/#/c/512522/ this should be public now. As a keystone core (not as a VMT member), I am moving this to a public bug.