Remote Code Execution in trove-conductor

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.

Hi Pavel, thanks for reporting this. I have several questions:

1. Which Trove version are you using for the testing?
2. Did you config service tenant model for Trove? In service tenant model (which is the default in devstack since stable/train and is recommended for Trove deployment[1]), all the resources created for a trove instance are located in the service tenant scope, and are invisible to normal users. So it's relatively impossible for malicious user to get into the instance and get message queue credentials.

[1]: https://docs.openstack.org/trove/latest/admin/run_trove_in_production.html#service-tenant-deployment

1. I tested it in ocata version, i did configure it myself, though. I checked the source in newest version and it seems that vulnerable part of source code wasn't changed.
2. No, my testing stand allowed me to detach root disk from trove instance and to attach it to nova instance. This way i was able to read the credentials

But still, i think it's better to fix that, because it can be used as a post-exploitation technique, when attacker somehow can read mq credentials by exploiting vulnerable DB or invalid configured custom DB image.

As I mentioned above, in production (especially public cloud), Trove should be deployed in service tenant model (actually we are not sure the flat model is still working because it's never tested in devstack), so that it's highly unlikely for the attacker to get MQ credentials, the trove-conductor can be only consumed by trove-guestagent running inside the instance.

Trove security issues have been discussed many times in history, one of the potential reasons is that normal user is able to see resources(VM, volume, etc.) created for a trove instance, that's the reason that service tenant model was introduced.

That being said, this bug is still valid but shouldn't be a security issue but an enhancement.

Starting with the Ussuri release, Trove's documentation includes this guidance:

"In production, almost all the cloud resources (except the Swift objects for backup data) created for a Trove instance should be only visible to the Trove service user. As DBaaS users, they should only see a Trove instance after creating, and know nothing about the Nova VM, Cinder volume, Neutron management network and security groups under the hood. The only way to operate Trove instance is to interact with Trove API."

https://docs.openstack.org/trove/ussuri/admin/run_trove_in_production.html#service-tenant-deployment

As such, I agree this is at the very least a known issue, already public, so there's no need to keep this report private. The documentation goes on to say that this recommendation is also the default deployment model for the service as of Ussuri. It doesn't look like this solution could be trivially backported to older versions, nor would doing so be of much help to anyone who has already deployed it following a less secure model. At most, we could consider publishing an OpenStack Security Note (effectively an appendix of the OpenStack Security Guide) to serve as a reminder that deployments which place these resources under direct control of the end user can leak sensitive data such as message bus authentication credentials.

I've switched the report to public and marked our security advisory task "won't fix" for now, pending any further discussion. This report is probably most closely aligned with Class B1 (possibly B2) for releases up through Train (fixed through documentation and default changes for Ussuri) in the OpenStack Vulnerability Management Team's taxonomy: https://security.openstack.org/vmt-process.html#incident-report-taxonomy