Several insecure /tmp usage in guestagent (CVE-2015-3156)
| 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:/
https:/
Redis:
https:/
https:/
Mysql:
https:/
https:/
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:/
https:/
- Couchbase also dump to a file in /tmp/ with a predictable name ( so usual overwrite attack, etc, etc )
https:/
- Mysql dump/restore modules also use a file in /tmp/ with a predictable and not verified name for logs :
https:/
https:/
https:/
CVE References
| Tristan Cacqueray (tristan-cacqueray) wrote | #1 |
| Changed in ossa: | |
| status: | New → Incomplete |
| summary: |
- Several insecure /tmp usage in guestagent + Several insecure /tmp usage in guestagent (CVE-2015-3156) |
| Tristan Cacqueray (tristan-cacqueray) wrote | #2 |
| Thierry Carrez (ttx) wrote | #3 |
| Tristan Cacqueray (tristan-cacqueray) wrote | #4 |
| Jeremy Stanley (fungi) wrote | #5 |
| Tristan Cacqueray (tristan-cacqueray) wrote | #6 |
| Changed in ossa: | |
| status: | Incomplete → Won't Fix |
| information type: | Private Security → Public |
| Changed in trove: | |
| assignee: | nobody → Amrith (amrith) |
| Changed in trove: | |
| assignee: | Amrith Kumar (amrith) → nobody |
| description: | updated |
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.