Insecure temporary file usage in Cassandra datastore
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack DBaaS (Trove) |
Fix Released
|
High
|
Amrith Kumar | ||
OpenStack Security Advisory |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
This code in the Cassandra datastore for Trove uses temporary files insecurely here:
https:/
Around the above line, config is written to a hardcoded file in /tmp and then copied (with sudo) to another hardcoded path. Since this path is hardcoded and in tmp (with no special permissions set on it), an attacker may be able to tamper with the contents of the file, or beat the legitimate code to the creation of the file. In either case, the attacker controlled config will be copied to the protected (as evidenced by the need for sudo) Cassandra config file path.
If temporary files are required, secure libraries/functions should be used instead. Potentially sensitive config data should be protected with adequate access controls at all times.
Changed in ossa: | |
status: | New → Incomplete |
Changed in trove: | |
assignee: | nobody → Amrith (amrith) |
Changed in trove: | |
assignee: | Amrith (amrith) → Denis M. (dmakogon) |
Changed in trove: | |
assignee: | Denis M. (dmakogon) → Amrith (amrith) |
Changed in trove: | |
milestone: | none → kilo-2 |
Changed in trove: | |
status: | Fix Committed → Fix Released |
Changed in trove: | |
milestone: | kilo-2 → 2015.1.0 |
I agree this sounds like a classic "predictable temporary file" vulnerability. Risk is likely low since the trove guest agent runs on trove instances which typically don't have untrusted local users in a typical deployment, though I suppose there might be some accessible database features capable of coaxing symlink creation to perform an overwrite attack on systems lacking sufficient in-kernel safeguards against that.
I've subscribed Trove core security reviewers to weigh in on the bug report and potential fixes.