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

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.

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.

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

The sanlock server creates the /var/log/sanlock.log world writable allowing any one on the system to wipe the contents of the log file or to store data within the log file (bypassing any quotas applied to their account). The affected code is:

src/log.h

int setuplogging(void) { int fd, rv; snprintf(logfilepath, PATHMAX, "%s/%s", SANLKLOGDIR, SANLKLOGFILENAME); logfilefp = fopen(logfilepath, "a+");

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

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

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/

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

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

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.

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.

The REST API in oVirt 3.4.0 and earlier stores session IDs in HTML5 local storage, which allows remote attackers to obtain sensitive information via a crafted web page.

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

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.

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.

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

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.

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

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.