ghsa

The Object module in Liferay Portal 7.4.3.4 through 7.4.3.48, and Liferay DXP 7.4 before update 49 does properly isolate objects in difference virtual instances, which allows remote authenticated users in one virtual instance to view objects in a different virtual instance via OAuth 2 scope administration page.

The Dynamic Data Mapping module in Liferay Portal 7.4.3.67, and Liferay DXP 7.4 update 67 does not limit Document and Media files which can be downloaded from a Form, which allows remote attackers to download any file from Document and Media via a crafted URL.

Cross-site scripting (XSS) vulnerability in Layout module in Liferay Portal 7.3.4 through 7.4.3.68, and Liferay DXP 7.3 before update 24, and 7.4 before update 69 allows remote attackers to inject arbitrary web script or HTML via a crafted payload injected into a container type layout fragment's `URL` text field.

In Liferay Portal 7.3.0 and earlier, and Liferay DXP 7.2 and earlier the default configuration does not require users to verify their email address, which allows remote attackers to create accounts using fake email addresses or email addresses which they don't control. The portal property `company.security.strangers.verify` should be set to true.

SQL injection vulnerability in the upgrade process for SQL Server in Liferay Portal 7.3.1 through 7.4.3.17, and Liferay DXP 7.3 before update 6, and 7.4 before update 18 allows attackers to execute arbitrary SQL commands via the name of a database table's primary key index. This vulnerability is only exploitable when chained with other attacks. To exploit this vulnerability, the attacker must modify the database and wait for the application to be upgraded.

Pattern Redirects in Liferay Portal 7.4.3.48 through 7.4.3.76, and Liferay DXP 7.4 update 48 through 76 allows regular expressions that are vulnerable to ReDoS attacks to be used as patterns, which allows remote attackers to consume an excessive amount of server resources via crafted request URLs.

### Impact Websites that use `Website.user_vars` property in versions. ### Patches It affects versions v2.0.1 to v2.4.0. Please upgrade to v2.4.1 ### Workarounds Do not use `Website.user_vars` in websites when using versions v2.0.1 to v2.4.0. Also, do not use `Website.signin_user()` in version v2.4.0 only. ### Explanation ToUI is using Flask-Caching (SimpleCache) to store user variables. My misunderstanding was that these caches are stored in the client's browser, but it seems that these are stored in the server side.

### Summary When building packages directly from source control, file permissions on the checked-in files are not maintained. ### Details When building packages directly from source control, file permissions on the checked-in files are not maintained. When nfpm packaged the files (without extra config for enforcing its own permissions) files could go out with bad permissions (chmod 666 or 777). ### PoC Create a default nfpm structure. Within the test folder, create 3 files named `chmod-XXX.sh`. Each script has file permissions set corresponding with their file names (`chmod-777.sh` = `chmod 777`). Below each file and permissions can be seen. ```console $ ls -lart test total 24 -rwxrwxrwx 1 user group 11 May 19 13:15 chmod-777.sh -rw-rw-rw- 1 user group 11 May 19 13:16 chmod-666.sh drwxr-xr-x 5 user group 160 May 19 13:19 . -rw-rw-r-- 1 user group 11 May 19 13:19 chmod-664.sh drwxr-xr-x 10 user group 320 May 19 13:29 .. ``` Below is the snippet nfpm confi...

### Impact A malicious user on a Synapse homeserver X with permission to create certain state events can disable outbound federation from X to an arbitrary homeserver Y. Synapse instances with federation disabled are not affected. #### Details The Matrix protocol allows homeservers to provide an `invite_room_state` field on a [room invite](https://spec.matrix.org/v1.5/client-server-api/#mroommember) containing a [summary of room state](https://spec.matrix.org/v1.5/client-server-api/#stripped-state). In versions of Synapse up to and including v1.73.0, Synapse did not limit the size of `invite_room_state`, meaning that it was possible to create an arbitrarily large invite event. An attacker with an account on a vulnerable Synapse homeserver X could exploit this by having X create an over-sized invite event in a room with a user from another homeserver Y. Once acknowledged by the invitee's homeserver, the invite event would be sent in a batch of events to Y. If the malicious invite ...

Specific vulnerabilities: * Arbitrary file write in `resource_create` and `package_update` actions, using the `ResourceUploader` object. Also reachable via `package_create`, `package_revise`, and `package_patch` via calls to `package_update`. * Remote code execution via unsafe pickle loading, via Beaker's session store when configured to use the file session store backend. * Potential DOS due to lack of a length check on the resource id. * Information disclosure: A user with permission to create a resource can access any other resource on the system if they know the id, even if they don't have access to it. * Resource overwrite: A user with permission to create a resource can overwrite any resource if they know the id, even if they don't have access to it. ### Impact A user with permissions to create or edit a dataset can upload a resource with a specially crafted id to write the uploaded file in an arbitrary location. This can be leveraged to Remote Code Execution via Beaker's i...