Several insecure /tmp usage in guestagent (CVE-2015-3156)

[Tristan Cacqueray]

Reported via private E-mail from Michael Scherer

- There is several instance of using a fixed name without verification for updating/resetting the configuration :

Mongodb:

https://github.com/openstack/trove/blob/master/trove/guestagent/datastore/experimental/mongodb/service.py#L176
https://github.com/openstack/trove/blob/master/trove/guestagent/datastore/experimental/mongodb/system.py#L26

Postgresql:
https://github.com/openstack/trove/blob/master/trove/guestagent/datastore/experimental/postgresql/service/config.py#L70

Redis:
https://github.com/openstack/trove/blob/master/trove/guestagent/datastore/experimental/redis/service.py#L30
https://github.com/openstack/trove/blob/master/trove/guestagent/datastore/experimental/redis/service.py#L236

Mysql:
https://github.com/openstack/trove/blob/master/trove/guestagent/datastore/mysql/service.py#L50
https://github.com/openstack/trove/blob/master/trove/guestagent/datastore/mysql/service.py#L790

Not that there is others occurrence of this pattern in the mysql part.

All of them are therefor vulnerable to someone injecting configuration, which could result in a privilege escalation.

- Cassandra use a /tmp file to run a command, without checking anything.
So this is vulnerable to a race condition and command injection by any local user to access the cassandra store.
https://github.com/openstack/trove/blob/master/trove/guestagent/datastore/experimental/cassandra/system.py#L33
https://github.com/openstack/trove/blob/master/trove/guestagent/datastore/experimental/cassandra/service.py#L230

- Couchbase also dump to a file in /tmp/ with a predictable name ( so usual overwrite attack, etc, etc )
https://github.com/openstack/trove/blob/master/trove/guestagent/strategies/backup/experimental/couchbase_impl.py#L30

- Mysql dump/restore modules also use a file in /tmp/ with a predictable and not verified name for logs :
https://github.com/openstack/trove/blob/master/trove/guestagent/strategies/restore/mysql_impl.py#L194
https://github.com/openstack/trove/blob/master/trove/guestagent/strategies/backup/mysql_impl.py#L55
https://github.com/openstack/trove/blob/master/trove/guestagent/strategies/backup/mysql_impl.py#L110

[Tristan Cacqueray (tristan-cacqueray)]

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.

I guess these issues boil down to whenever the guestagent is running on an exposed instance and/or shell access are being granted to user. I don't think this should be considered as a vulnerability per se, but better be safe than sorry.

[Tristan Cacqueray (tristan-cacqueray)]

Well it's very similar to https://launchpad.net/bugs/1398195

While these /tmp usage could be exploited remotely through a "SELECT INTO FILE" sql request, it's not clear whenever this deserve to stays under embargo and if it warrants an OSSA. Thought ?

[Thierry Carrez (ttx)]

Trove nodes are generally considered safe environments (no shell access, no local users) so unless one of the few processes it runs allows to dump stuff in a /tmp file, it's safe. I guess we should doublecheck who can trigger SELECT INTO FILE in Trove.

[Tristan Cacqueray (tristan-cacqueray)]

Tested on liberty using trove-integration script, the demo user is able to use the "root-enable" command which create an administrator account on the datastore.

So unless secure_file_priv (for mysql) is set, a user is able to create file in /tmp using SELECT INTO OUTFILE with the root account and leverage guest-agent /tmp usage to get shell access.

This seems like a serious enough flaw to warrant an advisory and fix the guest agent.

[Jeremy Stanley (fungi)]

In that PoC case it seems like the vulnerability is lack of proper remote isolation from the environment in which mysqld is running. The guest agent should of course be fixed regardless (defense in depth) but the ability to write arbitrary data to /tmp is the part which I think would take a user/deployer by surprise.

[Tristan Cacqueray (tristan-cacqueray)]

Oh yes, you're right, I overlooked the impact, select into does not allow symlink creation and it can't append to an existing file...

Unless there is something else, those /tmp usage could be fixed in the open and this bug does not warrant an OpenStack advisory.

Let's open this next Monday if no one complains.