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

Bug #1447871 reported by Tristan Cacqueray
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack DBaaS (Trove)
New
Undecided
Unassigned
OpenStack Security Advisory
Won't Fix
Undecided
Unassigned

Bug Description

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

CVE References

Revision history for this message
Tristan Cacqueray (tristan-cacqueray) wrote :

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.

Changed in ossa:
status: New → Incomplete
summary: - Several insecure /tmp usage in guestagent
+ Several insecure /tmp usage in guestagent (CVE-2015-3156)
Revision history for this message
Tristan Cacqueray (tristan-cacqueray) wrote :

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 ?

Revision history for this message
Thierry Carrez (ttx) wrote :

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.

Revision history for this message
Tristan Cacqueray (tristan-cacqueray) wrote :

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.

Revision history for this message
Jeremy Stanley (fungi) wrote :

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.

Revision history for this message
Tristan Cacqueray (tristan-cacqueray) wrote :

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.

Changed in ossa:
status: Incomplete → Won't Fix
information type: Private Security → Public
Amrith Kumar (amrith)
Changed in trove:
assignee: nobody → Amrith (amrith)
Amrith Kumar (amrith)
Changed in trove:
assignee: Amrith Kumar (amrith) → nobody
Jeremy Stanley (fungi)
description: updated
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers