Advisories for Pypi/Nova package

2024

OpenStack Nova vulnerable to unauthorized access to potentially sensitive data

In OpenStack Nova before 27.4.1, 28 before 28.2.1, and 29 before 29.1.1, by supplying a raw format image that is actually a crafted QCOW2 image with a backing file path or VMDK flat image with a descriptor file path, an authenticated user may convince systems to return a copy of the referenced file's contents from the server, resulting in unauthorized access to potentially sensitive data. All Nova deployments are affected. …

OpenStack Cinder, Glance, and Nova vulnerable to arbitrary file access

An issue was discovered in OpenStack Cinder through 24.0.0, Glance before 28.0.2, and Nova before 29.0.3. Arbitrary file access can occur via custom QCOW2 external data. By supplying a crafted QCOW2 image that references a specific data file path, an authenticated user may convince systems to return a copy of that file's contents from the server, resulting in unauthorized access to potentially sensitive data. All Cinder and Nova deployments are …

2023

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

An issue was discovered in OpenStack Cinder before 19.1.2, 20.x before 20.0.2, and 21.0.0; Glance before 23.0.1, 24.x before 24.1.1, and 25.0.0; and Nova before 24.1.2, 25.x before 25.0.2, and 26.0.0. By supplying a specially created VMDK flat image that references a specific backing file path, an authenticated user may convince systems to return a copy of that file's contents from the server, resulting in unauthorized access to potentially sensitive …

2022

OpenStack Nova Changing vnic_type breaks compute service restart

An issue was discovered in OpenStack Nova before 23.2.2, 24.x before 24.1.2, and 25.x before 25.0.2. By creating a neutron port with the direct vnic_type, creating an instance bound to that port, and then changing the vnic_type of the bound port to macvtap, an authenticated user may cause the compute service to fail to restart, resulting in a possible denial of service. Only Nova deployments configured with SR-IOV are affected.

OpenStack Nova Server Resource Faults Leak External Exception Details

An issue was discovered in OpenStack Nova before 17.0.12, 18.x before 18.2.2, and 19.x before 19.0.2. If an API request from an authenticated user ends in a fault condition due to an external exception, details of the underlying environment may be leaked in the response, and could include sensitive configuration or other data.

OpenStack Nova Live migration fails to update persistent domain XML

An issue was discovered in Guest.migrate in virt/libvirt/guest.py in OpenStack Nova before 19.3.1, 20.x before 20.3.1, and 21.0.0. By performing a soft reboot of an instance that has previously undergone live migration, a user may gain access to destination host devices that share the same paths as host devices previously referenced by the virtual machine on the source host. This can include block devices that map to different Cinder volumes …

OpenStack Nova can leak consoleauth token into log files

An issue was discovered in OpenStack Nova before 18.2.4, 19.x before 19.1.0, and 20.x before 20.1.0. It can leak consoleauth tokens into log files. An attacker with read access to the service's logs may obtain tokens used for console access. All Nova setups using novncproxy are affected. This is related to NovaProxyRequestHandlerBase.new_websocket_client in console/websocketproxy.py.

OpenStack Nova VMWare driver leaks rescued images

The VMWare driver in OpenStack Compute (Nova) 2013.2 through 2013.2.2 does not properly put VMs into RESCUE status, which allows remote authenticated users to bypass the quota limit and cause a denial of service (resource consumption) by requesting the VM be put into rescue and then deleting the image.

OpenStack Nova Scheduler denial of service through scheduler_hints

The Nova scheduler in OpenStack Compute (Nova) Folsom (2012.2) and Essex (2012.1), when DifferentHostFilter or SameHostFilter is enabled, allows remote authenticated users to cause a denial of service (excessive database lookup calls and server hang) via a request with many repeated IDs in the os:scheduler_hints section.

OpenStack Nova Router metadata queries are not restricted by tenant

Interaction error in OpenStack Nova and Neutron before Havana 2013.2.1 and icehouse-1 does not validate the instance ID of the tenant making a request, which allows remote tenants to obtain sensitive metadata by spoofing the device ID that is bound to a port, which is not properly handled by (1) api/metadata/handler.py in Nova and (2) the neutron-metadata-agent (agent/metadata/agent.py) in Neutron.

OpenStack Nova Information leak in libvirt LVM-backed instances

OpenStack Compute (Nova) Folsom before 2012.2.2 and Grizzly, when using libvirt and LVM backed instances, does not properly clear physical volume (PV) content when reallocating for instances, which allows attackers to obtain sensitive information by reading the memory of the previous logical volume (LV).

OpenStack Nova host data leak to vm instance in rescue mode

The instance rescue mode in OpenStack Compute (Nova) 2013.2 before 2013.2.3 and Icehouse before 2014.1, when using libvirt to spawn images and use_cow_images is set to false, allows remote authenticated users to read certain compute host files by overwriting an instance disk with a crafted image.

OpenStack Nova Directory traversal vulnerability

Directory traversal vulnerability in virt/disk/api.py in OpenStack Compute (Nova) Folsom (2012.2) and Essex (2012.1), when used over libvirt-based hypervisors, allows remote authenticated users to write arbitrary files to the disk image via a .. (dot dot) in the path attribute of a file element.

OpenStack Compute Nova Improper Access Control

The XenAPI backend in OpenStack Compute (Nova) Folsom, Grizzly, and Havana before 2013.2 does not properly apply security groups (1) when resizing an image or (2) during live migration, which allows remote attackers to bypass intended restrictions.

OpenStack Compute (Nova) Improper Input Validation

The (1) EC2 and (2) OS APIs in OpenStack Compute (Nova) Folsom (2012.2), Essex (2012.1), and Diablo (2011.3) do not properly check the protocol when security groups are created and the network protocol is not specified entirely in lowercase, which allows remote attackers to bypass intended access restrictions.

OpenStack Compute (Nova) Denial of service due to improper validation of virtual size of QCOW2 image

OpenStack Compute (Nova) Folsom, Grizzly, and Havana, when use_cow_images is set to False, does not verify the virtual size of a QCOW2 image, which allows local users to cause a denial of service (host file system disk consumption) by transferring an image with a large virtual size that does not contain a large amount of data from Glance. NOTE: this issue is due to an incomplete fix for CVE-2013-2096.

Arbitrary file overwrite in OpenStack Nova

virt/disk/api.py in OpenStack Compute (Nova) 2012.1.x before 2012.1.2 and Folsom before Folsom-3 allows remote authenticated users to overwrite arbitrary files via a symlink attack on a file in an image that uses a symlink that is only readable by root. NOTE: this vulnerability exists because of an incomplete fix for CVE-2012-3361.

OpenStack Nova host data access through resize/migration

The libvirt driver in OpenStack Compute (Nova) before 2015.1.4 (kilo) and 12.0.x before 12.0.3 (liberty), when using raw storage and use_cow_images is set to false, allows remote authenticated users to read arbitrary files via a crafted qcow2 header in an ephemeral or root disk.

OpenStack Nova DoS through ephemeral disk backing files

The libvirt driver in OpenStack Compute (Nova) before 2013.2.2 and icehouse before icehouse-2 allows remote authenticated users to cause a denial of service (disk consumption) by creating and deleting instances with unique os_type settings, which triggers the creation of a new ephemeral disk backing file.

OpenStack Nova Denial of Service in network source security groups

Algorithmic complexity vulnerability in OpenStack Compute (Nova) before 2013.1.3 and Havana before havana-3 does not properly handle network source security group policy updates, which allows remote authenticated users to cause a denial of service (nova-network consumption) via a large number of server-creation operations, which triggers a large number of update requests.

OpenStack Compute (Nova) Denial of Service vulnerability

A denial of service flaw was found in the way OpenStack Compute (nova) looked up VM instances based on an IP address filter. An attacker with sufficient privileges on an OpenStack installation with a large amount of VMs could use this flaw to cause the main nova process to block for an extended amount of time.

OpenStack Cinder, Glance, and Nova contain Uncontrolled Resource Consumption

A resource vulnerability in the OpenStack Compute (nova), Block Storage (cinder), and Image (glance) services was found in their use of qemu-img. An unprivileged user could consume as much as 4 GB of RAM on the compute host by uploading a malicious image. This flaw could lead possibly to host out-of-memory errors and negatively affect other running tenant instances. oslo.concurrency has been updated to support process limits ('prlimit'), which is …

Insufficient Verification of Data Authenticity

It was discovered that the OpenStack Compute (nova) console websocket does not correctly verify the origin header. An attacker could use this flaw to conduct a cross-site websocket hijack attack. Note that only Compute setups with VNC or SPICE enabled were affected by this flaw.

Exposure of Sensitive Information to an Unauthorized Actor

api/metadata/handler.py in OpenStack Compute (Nova) before 2013.2.4, 2014.x before 2014.1.2, and Juno before Juno-2, when proxying metadata requests through Neutron, makes it easier for remote attackers to guess instance ID signatures via a brute-force attack that relies on timing differences in responses to instance metadata requests.

OpenStack Nova Potential Xen connection password leak via StorageError

The volume_utils._parse_volume_info function in OpenStack Compute (Nova) before 2015.1.3 (kilo) and 12.0.x before 12.0.1 (liberty) includes the connection_info dictionary in the StorageError message when using the Xen backend, which might allow attackers to obtain sensitive password information by reading log files or other unspecified vectors.

OpenStack Nova Filter Scheduler Bypass

In OpenStack Nova through 14.0.9, 15.x through 15.0.7, and 16.x through 16.0.2, by rebuilding an instance, an authenticated user may be able to circumvent the Filter Scheduler bypassing imposed filters (for example, the ImagePropertiesFilter or the IsolatedHostsFilter). All setups using Nova Filter Scheduler are affected. Because of the regression described in Launchpad Bug #1732947, the preferred fix is a 14.x version after 14.0.10, a 15.x version after 15.0.8, or a …

OpenStack Nova DoS by rebuilding the same instance with a new image multiple times

An issue was discovered in the default FilterScheduler in OpenStack Nova 16.0.3. By repeatedly rebuilding an instance with new images, an authenticated user may consume untracked resources on a hypervisor host leading to a denial of service, aka doubled resource allocations. This regression was introduced with the fix for OSSA-2017-005 (CVE-2017-16239); however, only Nova stable/pike or later deployments with that fix applied and relying on the default FilterScheduler are affected.

OpenStack Nova Denial of service attack on the compute host

An issue was discovered in OpenStack Nova 15.x through 15.1.0 and 16.x through 16.1.1. By detaching and reattaching an encrypted volume, an attacker may access the underlying raw volume and corrupt the LUKS header, resulting in a denial of service attack on the compute host. (The same code error also results in data loss, but that is not a vulnerability because the user loses their own data.) All Nova setups …

OpenStack Nova Exposure of Sensitive Information to an Unauthorized Actor

OpenStack Nova before 2012.1 allows someone with access to an EC2_ACCESS_KEY (equivalent to a username) to obtain the EC2_SECRET_KEY (equivalent to a password). Exposing the EC2_ACCESS_KEY via http or tools that allow man-in-the-middle over https could allow an attacker to easily obtain the EC2_SECRET_KEY. An attacker could also presumably brute force values for EC2_ACCESS_KEY.