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 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 VM, potentially sensitive data could be revealed to privileged users of that VM.
An information disclosure in ovirt-hosted-engine-setup prior to 2.2.7 reveals the root user's password in the log file.
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 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.
Cross-site request forgery (CSRF) vulnerability in oVirt Engine before 3.5.0 beta2 allows remote attackers to hijack the authentication of users for requests that perform unspecified actions via a REST API request.
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
An XSS vulnerability was found in ovirt-engine when submitting configuration file used to build up the VNC/SPICE-Connection. The file is automatically generated without any user input on the client side and uploaded to the server, which immediately reflects that upload. Legitimate HTTP Request looks aas following:
POST /ovirt-engine/services/attachment/console.vv
contenttype=application%2Fx-virt-viewer%3B+charset%3DUTF-8&content=[...configuration file...]&encodingtype=plain
Web application accepts the POST-Parameter contenttype, that sets the Content-Type of the HTTP-Response of the reflected upload. When setting the contenttype to text/html, it allows to inject malicious JavaScript code to be reflected on the page. The attacker could send RPC-Requests via XHR with the privileges of the victim. If the victim is logged in, the attacker can inject a JavaScript code that sends a RPC-Request to start, stop or manipulate a specific VM.
It was found that parsing complicated kernel version numbers leads to array index out-of-bounds exception in VersionMapper.fromKernelVersionString method. A malicious user with access to VM could configure it so that it reports a version number that causes API to crash. When the VM with crafted kernel version number is reported among with other VMs, the representation retrieving operation will fail also for all other VMs.
Product bug:
https://bugzilla.redhat.com/showbug.cgi?id=1311616
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 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.
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.
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.
A cross-site scripting (XSS) flaw was found in the RedirectServlet of the oVirt Engine and Red Hat Enterprise Virtualization Manager (RHEV-M). A remote attacker could provide a specially-crafted link, that when visited by an unsuspecting RHEV-M / oVirt user would lead to arbitrary script execution in the context of the RHEV-M / oVirt domain. Access to the RedirectServlet does not require authentication.
An HTML injection/reflected XSS vulnerability is 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. Several filtering and escaping techniques can be used to mitigate these input validation vulnerabilities.
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.