6 posts tagged with "security"

The vulnerability​

When talking to the OpenStack Nova Compute API, Users can specify scheduler hints, expressing preferences for Server (VM) placement. Users can however inject a values {"_nova_check_type": "rebuild"} that is only meant to be used internally in the rebuild context which causes certain resource checks to be skipped. This can cause placement contraints such as host aggregates, AZs, image traits to be ignored and cause PCI pass-through resources to not be properly mapped. While the assigned quota is still observed, the vulnerability may cause exhaustion of resources and confusion of the scheduler (placement) state and thus may result in a Denial of Service for certain resource types.

The vulnerabilities​

A series of five related vulnerabilities has been identified in OpenStack Keystone that impact how credentials are delegated and how authorization policies are enforced. These vulnerabilities allow authenticated attackers to bypass security boundaries, impersonate users, and potentially escalate privileges to cloud administrator.

Linux root exploits (Local Privilege Escalation)​

Unix is designed as a multi-user system. Different users have their own files and processes and can work without interference from others. Linux lives in that tradition. It has advanced the concept with namespaces where users can also have a private view on networking, process list, filesystems and other pieces that are traditionally shared (read-only) on a Unix system, also including some resource management to enhance performance isolation.

It is the operating system's kernel's job to keep the separation safe; in particular, normal users must not achieve the system administrator (root) privileges. Where the kernel fails to ensure this, we have a "local root" vulnerability, a Local Privilege Escalation (LPE).

The vulnerability​

OpenStack allows the creation of Application Credentials to give its bearer access to a project with the privileges of the user who created the AppCreds. Application Credentials can have a limited lifetime and can be revoked. They can also be restricted (which means that they can not be used to create additional application credentials) or can be assigned roles with lower privileges, limiting the privileges that the bearer has.

When AppCreds are used to create EC2 credentials, keystone failed to require unrestricted AppCreds and failed to require the member role, giving AppCreds that are restricted or that have limited roles the ability to create EC2 credentials with the full privileges of the user who created the AppCred.

The vulnerability​

OpenStack supports a variety of image formats to ease migration from other virtualization platforms. The qemu-img tools are used to deal with these images. Unfortunately, OpenStack developers had to learn that qemu-img is not as robust as expected when dealing with untrusted images. This has lead to CVE-2022-47951 and CVE-2024-32498 and CVE-2024-40767 .

Analyzing all potentially vulnerable code paths, at least one had been overlooked by developers before: When resizing VMs in Nova to a flavor with a new root disk/ephemeral disk size, and Nova's flat image backend is in use, qemu-img is called on the backing image file without an explicit format specifier, opening up the possibility to overwrite files on the host system by writing a malicious QCOW header to a root or ephemeral disk.

Prefix​

This advisory was drafted a few days ago, before the issue was public. As the issue turned out to only affect very specific configurations (which are not used in any standard SCS setting), we did not publish it with the urgency that we normally apply to protect our partners in time for a vulnerability becoming public.

Instead, we have taken the time to sort out the publication place in the the new Docs blog space, as described by the previous blog post.