Vulnerabilidades

vdsm: certificate generation upon node creation allowing vdsm to start and serve requests from anyone who has a matching key (and certificate)

oVirt users with MANIPULATE_STORAGE_DOMAIN permissions can attach a storage domain to any data-center

ovirt-engine 3.2 running on Linux kernel 3.1 and newer creates certain files world-writeable due to an upstream kernel change which impacted how python's os.chmod() works when passed a mode of '-1'.

Sensitive passwords used in deployment and configuration of oVirt Metrics, all versions. were found to be insufficiently protected. Passwords could be disclosed in log files (if playbooks are run with -v) or in playbooks stored on Metrics or Bastion hosts.

During HE deployment via cockpit-ovirt, cockpit-ovirt generates an ansible variable file `/var/lib/ovirt-hosted-engine-setup/cockpit/ansibleVarFileXXXXXX.var` which contains the admin and the appliance passwords as plain-text. At the of the deployment procedure, these files are deleted.

It was discovered that in the ovirt's REST API before version 4.3.2.1, RemoveDiskCommand is triggered as an internal command, meaning the permission validation that should be performed against the calling user is skipped. A user with low privileges (eg Basic Operations) could exploit this flaw to delete disks attached…

A vulnerability was discovered in vdsm, version 4.19 through 4.30.3 and 4.30.5 through 4.30.8. The systemd_run function exposed to the vdsm system user could be abused to execute arbitrary commands as root.

In ovirt-engine 4.1, if a host was provisioned with cloud-init, the root password could be revealed through the REST interface.

An issue was discovered in Microvirt MEmu 6.0.6. The MemuService.exe service binary is vulnerable to local privilege escalation through binary planting due to insecure permissions set at install time. This allows code to be run as NT AUTHORITY/SYSTEM.

It was found that vdsm before version 4.20.37 invokes qemu-img on untrusted inputs without limiting resources. By uploading a specially crafted image, an attacker could cause the qemu-img process to consume unbounded amounts of memory of CPU time, causing a denial of service condition that could potentially impact…

ovirt-engine before version 4.1.7.6 with log level set to DEBUG includes passwords in the log file without masking. Only administrators can change the log level and only administrators can access the logs. This presents a risk when debug-level logs are shared with vendors or other parties to troubleshoot issues.

ovirt-engine before version ovirt 4.2.2 is vulnerable to an information exposure through log files. When engine-backup was run with one of the options "--provision*db", the database username and password were logged in cleartext. Sharing the provisioning log might inadvertently leak database passwords.

ovirt-ansible-roles before version 1.0.6 has a vulnerability due to a missing no_log directive, resulting in the 'Add oVirt Provider to ManageIQ/CloudForms' playbook inadvertently disclosing admin passwords in the provisioning log. In an environment where logs are shared with other parties, this could lead to…

The web console login form in ovirt-engine before version 4.2.3 returned different errors for non-existent users and invalid passwords, allowing an attacker to discover the names of valid user accounts.

ovirt-engine up to version 4.2.3 is vulnerable to an unfiltered password when choosing manual db provisioning. When engine-setup was run and one chooses to provision the database manually or connect to a remote database, the password input was logged in cleartext during the verification step. Sharing the provisioning…

ovirt-engine API and administration web portal before versions 4.2.2.5, 4.1.11.2 is vulnerable to an exposure of Power Management credentials, including cleartext passwords to Host Administrators. A Host Administrator could use this flaw to gain access to the power management systems of hosts they control.

oVirt version 4.2.0 to 4.2.2 contains a Cross Site Scripting (XSS) vulnerability in the name/description of VMs portion of the web admin application. This vulnerability appears to have been fixed in version 4.2.3.

A vulnerability was discovered in oVirt 4.1.x before 4.1.9, where the combination of Enable Discard and Wipe After Delete flags for VM disks managed by oVirt, could cause a disk to be incompletely zeroed when removed from a VM. If the same storage blocks happen to be later allocated to a new disk attached to another…

An information disclosure in ovirt-hosted-engine-setup prior to 2.2.7 reveals the root user's password in the log file.

oVirt 3.2.2 through 3.5.0 does not invalidate the restapi session after logout from the webadmin, which allows remote authenticated users with knowledge of another user's session data to gain that user's privileges by replacing their session token with that of another user.

ovirt_safe_delete_config in ovirtfunctions.py and other unspecified locations in ovirt-node 3.0.0-474-gb852fd7 as packaged in Red Hat Enterprise Virtualization 3 do not properly quote input strings, which allows remote authenticated users and physically proximate attackers to execute arbitrary commands via a ;…

Cross-site scripting (XSS) vulnerability in ovirt-engine allows remote attackers to inject arbitrary web script or HTML.

The VersionMapper.fromKernelVersionString method in oVirt Engine allows remote authenticated users to cause a denial of service (process crash) for all VMs.

oVirt Engine before 4.0.3 does not include DWH_DB_PASSWORD in the list of keys to hide in log files, which allows local users to obtain sensitive password information by reading engine log files.

oVirt Engine before 3.5.0 does not include the HTTPOnly flag in a Set-Cookie header for the session IDs, which makes it easier for remote attackers to obtain potentially sensitive information via script access to this cookie.