Уязвимости lxd · Страница 2

Project restriction `restricted.containers.privilege=isolated` bypassable by omitting `security.idmap.isolated`

An authorization bypass vulnerability in LXD allows an authenticated attacker to bypass project-level container isolation restrictions. When a project is configured with restrictions on container privileges (such as enforcing restricted.containers.privilege=isolated), LXD fails to enforce the requirement if an instance configuration omits the security.idmap.isolated key. An attacker can exploit this flaw by creating or updating an instance without explicitly setting security.idmap.isolated, bypassing the target project's security constraints.

Project restriction bypass via instance migration config override

An authorization bypass vulnerability in LXD allows an authenticated attacker to bypass target project restrictions during instance migration. When migrating an instance to a target project, LXD accepts configuration overrides without validating the new configuration against the target project's enforced restrictions. An attacker can exploit this flaw to move instances with disallowed high-privilege configurations into restricted projects, bypassing security controls.

Cross-project instance copy bypasses target project restrictions via TOCTOU in config merge

An authorization bypass vulnerability in LXD due to a timing flaw during configuration merging allows an authenticated attacker to bypass target project restrictions during cross-project instance copies. When copying an instance to a target project, LXD performs restriction checks before configuration merging is complete, creating a time-of-check to time-of-use (TOCTOU) condition. An attacker can exploit this flaw to copy instances with disallowed high-privilege configurations into restricted projects, bypassing security controls.

LXD arbitrary lxc.conf directive injection via NVIDIA instance configuration

An improper neutralization of special elements vulnerability in LXD's NVIDIA instance configuration handling allows an authenticated attacker to inject arbitrary configuration directives. By supplying newline characters within the 'nvidia.driver.capabilities' or 'nvidia.require.*' configuration values, an attacker can manipulate the generated lxc.conf file. This flaw enables the attacker to execute arbitrary code on the host system with the privileges of the LXD daemon.

Storage volume cross-project move and snapshot restore bypass project disk limits

An authorization bypass vulnerability in LXD allows an authenticated user to bypass project-level disk and volume limits. Two related code paths fail to verify resource limits during volume operations: the storagePoolVolumeTypePostMove function omits the limits.AllowVolumeCreation check before moving a volume across projects, and volume snapshot restore operations skip the AllowVolumeUpdate check when the configuration is nil (Config == nil). An attacker can exploit these flaws to allocate storage resources that exceed the administrative limits configured for a project.

Cross-project cluster migration bypasses project restrictions via cluster notification flag

An authorization bypass vulnerability in LXD allows an authenticated attacker to bypass target project security restrictions during cross-project instance migrations. When moving an instance cross-project to a different cluster member via POST /1.0/instances/{name} with migration: true, project: <target>, and target: <member>, the destination node skips all project restriction checks because the request arrives as an internal cluster notification. An attacker can exploit this to introduce disallowed instance configurations into a restricted project.

Cross-project instance move bypasses all project restrictions allowing host command execution

An improper validation vulnerability in the instancePostMigration function in lxd/instance_post.go of LXD allows an authenticated attacker with can_create_instances permissions on a restricted project to bypass project-level security restrictions. When migrating an instance between projects, LXD fails to validate the instance's configuration against the target project's enforced restrictions (such as restricted.containers.lowlevel, restricted.devices.*, and restricted.networks.access). An attacker can exploit this by creating a disallowed or high-privilege instance in an unrestricted project and subsequently moving it into the restricted proj

SSRF via image import from URL allows internal network probing by authenticated users

In Canonical LXD versions 4.12 through 6.9, a Server-Side Request Forgery (SSRF) vulnerability in the image import functionality allows authenticated users with the can_create_images entitlement to interact with internal network infrastructure via the /images endpoint. When importing an image from a URL source, the LXD daemon fails to validate or restrict outbound destination IP addresses, allowing connections to loopback, RFC1918 private ranges, and cloud metadata endpoints. This enables error-based port scanning and unauthorized interaction with internal HTTP services from the daemon's network position.

LXD Snapshot Import Privilege Escalation Vulnerability

A privilege escalation vulnerability exists in LXD from 6.0 before 6.9, 5.21.0 before 5.21.5, and 5.0.0 before 5.0.7 regarding the handling of project-restriction policies during snapshot restoration.. An authenticated project operator in a restricted multi-tenant environment can bypass policy restrictions by importing a maliciously crafted instance backup containing restricted configuration keys within a snapshot. When the snapshot is restored, these restricted keys are applied to the live instance without policy validation. Starting the modified instance grants the operator unauthorized host root access.

• Обновитесь до 5.0.2+git20231211.1364ae4-9+deb13u7

Authenticated Denial of Service via Malicious Backup Tarball in LXD

Nil-pointer dereference in CreateCustomVolumeFromBackup in LXD up to version 6.8 and 5.21 on Linux allows an authenticated user with can_create_storage_volumes permissions to cause a denial of service via a specially crafted custom-volume backup tarball that omits the expires_at snapshot field.

• Обновитесь до 5.0.2+git20231211.1364ae4-9+deb13u7

Incus: Unbounded binary import disk exhaustion

Incus is a system container and virtual machine manager. Prior to version 7.0.0, uploads of large amount of data by authenticated users can run the Incus server out of disk space, potentially taking down the host system. The impact here is limited for anyone using storage.images_volume and storage.backups_volume as those users will have large uploads be stored on those volumes rather than directly on the host filesystem. This is the default behavior on IncusOS. This issue has been patched in version 7.0.0.

• Обновитесь до 5.0.2+git20231211.1364ae4-9+deb13u6

Incus: Nil Dereferences on Restore via Malformed YAML

Incus is a system container and virtual machine manager. Prior to version 7.0.0, backup.GetInfo() trusts the inline backup/index.yaml config when present and only falls back to parsing the legacy backup/container/backup.yaml file if result.Config == nil. As a result, an archive can carry a valid inline config that passes the initial import preflight while also carrying a malformed legacy backup/container/backup.yaml file that is reparsed later from the restored file system. ParseConfigYamlFile() accepts YAML documents with no container section, and multiple downstream consumers then dereference. Container without checking for nil. Confirmed e

• Обновитесь до 5.0.2+git20231211.1364ae4-9+deb13u6

Incus: Unbounded YAML Metadata Decode via Parsing

Incus is a system container and virtual machine manager. Prior to version 7.0.0, user provided image and backup tarballs would be unpacked and YAML files parsed without any size restrictions. This was making it easy for an authenticated user to provide a crafted image or backup tarball that when parsed by Incus would lead to a very large YAML document being loaded into memory, potentially causing the entire server to run out of memory. This issue has been patched in version 7.0.0.

• Обновитесь до 5.0.2+git20231211.1364ae4-9+deb13u6

Incus out-of-bounds panic in snapshot metadata handling allows denial of service

Incus is a system container and virtual machine manager. In versions before 7.0.0, missing validation logic in the storage volume import logic allows an authenticated user with access to the storage volume feature to cause the Incus daemon to crash. The backup restore subsystem contains an out-of-bounds panic vulnerability caused by an invalid bounds check when indexing snapshot metadata arrays, and the same flawed pattern also appears in the migration path. When iterating through physical snapshots provided in a backup archive, the loop uses the index to look up corresponding metadata in the parsed `Config.Snapshots` and `Config.VolumeSnapsh

• Обновитесь до 5.0.2+git20231211.1364ae4-9+deb13u6

Incus nil-pointer dereference in custom volume import allows denial of service

Incus is a system container and virtual machine manager. In versions before 7.0.0, missing validation logic in the storage volume import logic allows an authenticated user with access to the storage volume feature to cause the Incus daemon to crash. The custom volume backup import subsystem contains a nil-pointer dereference vulnerability during import operations. In the snapshot import loop, the daemon iterates over entries from `srcBackup.Config.VolumeSnapshots` and assumes that each slice element is initialized, then dereferences fields such as `Name`, `Config`, `Description`, `CreatedAt`, and `ExpiresAt` without first validating the eleme

• Обновитесь до 5.0.2+git20231211.1364ae4-9+deb13u6

Update of type field in restricted TLS certificate allows privilege escalation to cluster admin

In Canonical LXD versions 4.12 through 6.7, the doCertificateUpdate function in lxd/certificates.go does not validate the Type field when handling PUT/PATCH requests to /1.0/certificates/{fingerprint} for restricted TLS certificate users, allowing a remote authenticated attacker to escalate privileges to cluster admin.

• Обновитесь до 5.0.2+git20231211.1364ae4-9+deb13u5

Importing a crafted backup leads to project restriction bypass

In Canonical LXD before 6.8, the backup import path validates project restrictions against backup/index.yaml in the supplied tar archive but creates the instance from backup/container/backup.yaml, a separate file in the same archive that is never checked against project restrictions. An authenticated remote attacker with instance-creation permission in a restricted project can craft a backup archive where backup.yaml carries restricted settings such as security.privileged=true or raw.lxc directives, bypassing all project restriction enforcement and allowing full host compromise.

• Обновитесь до 5.0.2+git20231211.1364ae4-9+deb13u5

VM lowlevel restriction bypass via raw.apparmor and raw.qemu.conf

Canonical LXD versions 4.12 through 6.7 contain an incomplete denylist in isVMLowLevelOptionForbidden (lxd/project/limits/permissions.go), which omits raw.apparmor and raw.qemu.conf from the set of keys blocked under the restricted.virtual-machines.lowlevel=block project restriction. A remote attacker with can_edit permission on a VM instance in a restricted project can inject an AppArmor rule and a QEMU chardev configuration that bridges the LXD Unix socket into the guest VM, enabling privilege escalation to LXD cluster administrator and subsequently to host root.

• Обновитесь до 5.0.2+git20231211.1364ae4-9+deb13u5

lxd - security update

lxd - security update

• Обновитесь до 5.0.2+git20231211.1364ae4-9+deb13u4

Incus vulnerable to arbitrary file read and write through pongo templates

Incus is a system container and virtual machine manager. Prior to version 6.23.0, instance template files can be used to cause arbitrary read or writes as root on the host server. Incus allows for pongo2 templates within instances which can be used at various times in the instance lifecycle to template files inside of the instance. This particular implementation of pongo2 within Incus allowed for file read/write but with the expectation that the pongo2 chroot feature would isolate all such access to the instance's filesystem. This was allowed such that a template could theoretically read a file and then generate a new version of said file. Un

• Обновитесь до 5.0.2+git20231211.1364ae4-9+deb13u4