ghsa

The PBKDF2-based JWE key management algorithms expect a JOSE Header Parameter named `p2c` ([PBES2 Count](https://www.rfc-editor.org/rfc/rfc7518.html#section-4.8.1.2)), which determines how many PBKDF2 iterations must be executed in order to derive a CEK wrapping key. The purpose of this parameter is to intentionally slow down the key derivation function in order to make password brute-force and dictionary attacks more expensive. This makes the PBES2 algorithms unsuitable for situations where the JWE is coming from an untrusted source: an adversary can intentionally pick an extremely high PBES2 Count value, that will initiate a CPU-bound computation that may take an unreasonable amount of time to finish. ### Impact Under certain conditions (see below) it is possible to have the user's environment consume unreasonable amount of CPU time. ### Affected users The impact is limited only to users utilizing the JWE decryption APIs with symmetric secrets to decrypt JWEs from untrusted part...

### Impact If a vunerable version of cruddl is used to generate a schema that uses `@flexSearchFulltext`, users of that schema may be able to inject arbitrary AQL queries that will be forwarded to and executed by ArangoDB. Schemas that do not use `@flexSearchFulltext` are not affected. The attacker needs to have `READ` permission to at least one root entity type that has `@flexSearchFulltext` enabled. ### Patches The issue has been fixed in version 3.0.2 and in version 2.7.0 of cruddl. ### Workarounds Users can temporarily remove `@flexSearchFulltext` from their schemas before they can update cruddl. ### For more information If you have any questions or comments about this advisory: * Open an issue in [cruddl](https://github.com/AEB-labs/cruddl) * Email us at [[email protected]](mailto:[email protected])

### Impact The Rego compiler provides a (deprecated) `WithUnsafeBuiltins` function, which allows users to provide a set of built-in functions that should be deemed unsafe — and as such rejected — by the compiler if encountered in the policy compilation stage. A bypass of this protection has been found, where the use of the `with` keyword to mock such a built-in function (a feature introduced in OPA v0.40.0), isn’t taken into account by `WithUnsafeBuiltins`. The same method is exposed via `rego.UnsafeBuiltins` in the `github.com/open-policy-agent/opa/rego` package. When provided e.g. the `http.send` built-in function to `WithUnsafeBuiltins`, the following policy would still compile, and call the `http.send` function with the arguments provided to the `is_object` function when evaluated: ```rego package policy foo := is_object({ "method": "get", "url": "https://www.openpolicyagent.org" }) allow := r { r := foo with is_object as http.send } ``` Both built-in functions ...

## Impact _What kind of vulnerability is it? Who is impacted?_ This vulnerability impacts all the initialization functions on the `Heap` and `LockedHeap` types, including `Heap::new`, `Heap::init`, `Heap::init_from_slice`, and `LockedHeap::new`. It also affects multiple uses of the `Heap::extend` method. ### Initialization Functions The heap initialization methods were missing a minimum size check for the given heap size argument. This could lead to **_out-of-bound writes_** when a heap was initialized with a size smaller than `3 * size_of::<usize>` because of metadata write operations. ### `Heap::extend` This vulnerability impacts three specific uses of the `Heap::extend` method: - When calling `Heap::extend` with a size smaller than two `usize`s (e.g., 16 on `x86_64`), the size was erroneously rounded up to the minimum size, which could result in an **_out-of-bounds write_**. - Calling `Heap::extend` on an empty heap tried to construct a heap starting at address 0, which is als...

### Impact Some resources are missing a check for inactive (not yet activated or disabled) users in XWiki, including the REST service: so a disabled user can enable themselves using a REST call. On the same way some resources handler created by extensions are not protected by default: so an inactive users could perform actions for such extensions. This issue exists since at least version 1.1 of XWiki for instance configured with the email activation required for new users. Now it's more critical for newer versions (>= 11.3RC1) since we provided the capability to disable user without deleting them, and we encouraged using that feature. ### Patches This issue has been patched in XWiki 14.3RC1 and XWiki 13.10.5. ### Workarounds There is no workaround for this other than upgrading XWiki. ### References * https://jira.xwiki.org/browse/XWIKI-19559 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.x...

### Impact Through the suggestion feature, string and list properties of objects the user shouldn't have access to can be accessed. This includes private personal information like email addresses and salted password hashes of registered users but also other information stored in properties of objects. Sensitive configuration fields like passwords for LDAP or SMTP servers could be accessed. By exploiting an additional vulnerability, this issue can even be exploited on [private wikis](https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Access%20Rights/#HPrivateWiki) at least for string properties. ### Patches The issue is patched in version 13.10.4 and 14.2. Password properties are no longer displayed and rights are checked for other properties. ### Workarounds The template file `suggest.vm` can be replaced by a patched version without upgrading or restarting XWiki unless it has been [overridden](https://extensions.xwiki.org/xwiki/bin/view/Extension/Skin%20Application#HHowtoo...

### Impact It's possible to store a JavaScript which will be executed by anyone viewing the deleted attachments index with an attachment containing javascript in its name. For example, attachment a file with name `><img src=1 onerror=alert(1)>.jpg` will execute the alert. ### Patches This issue has been patched in XWiki 13.10.6 and 14.3. ### Workarounds It is possible to modify fix the vulnerability by editing the wiki page `XWiki.DeletedAttachments` with the object editor, open the `JavaScriptExtension` object and apply on the content the changes that can be found on the commit https://github.com/xwiki/xwiki-platform/commit/6705b0cd0289d1c90ed354bd4ecc1508c4b25745. ### References * https://jira.xwiki.org/browse/XWIKI-19613 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.xwiki.org/) * Email us at [Security Mailing List](mailto:[email protected])

### Impact It's possible to store JavaScript in an attachment name, which will be executed by anyone trying to move the corresponding attachment. For example, an attachment with name `><img src=1 onerror=alert(1)>.jpg` will execute the alert. ### Patches This issue has been patched in XWiki 14.4RC1. ### Workarounds It is possible to fix the vulnerability by copying [moveStep1.vm](https://raw.githubusercontent.com/xwiki/xwiki-platform/xwiki-platform-14.0-rc-1/xwiki-platform-core/xwiki-platform-attachment/xwiki-platform-attachment-api/src/main/resources/templates/attachment/moveStep1.vm) to `webapp/xwiki/templates/moveStep1.vm` and replace ``` #set($titleToDisplay = $services.localization.render('attachment.move.title', [$attachment.name, $escapetool.xml($doc.plainTitle), $doc.getURL()])) ``` by ``` #set($titleToDisplay = $services.localization.render('attachment.move.title', [ $escapetool.xml($attachment.name), $escapetool.xml($doc.plainTitle), $escapetool.xml($doc.g...

### Impact It's possible to store Javascript or groovy scripts in an mention macro anchor or reference field. The stored code is executed by anyone visiting the page with the mention. For example, the example below will create a file at `/tmp/exploit.txt`: ``` {{mention reference="XWiki.Translation" anchor="{{/html~}~}{{async async=~"true~" cached=~"false~" context=~"doc.reference~"~}~}{{groovy~}~}new File(~"/tmp/exploit.txt~").withWriter { out -> out.println(~"owned!~"); }{{/groovy~}~}{{/async~}~}"/}} ``` ### Patches This issue has been patched on XWiki 14.4 and 13.10.6. ### Workarounds It's possible to fix the vulnerability by updating `XWiki.Mentions.MentionsMacro` and edit the `Macro code` field of the `XWiki.WikiMacroClass` XObject. ```velocity <a id="$anchor" class="$stringtool.join($cssClasses, ' ')" data-reference="$services.model.serialize($reference.reference, 'default')" href="$link">$content</a> ``` Must be replaced by ```velocity <a id="$escapetool.xml($anchor)" cl...

### Impact It's possible to inject arbitrary wiki syntax including Groovy, Python and Velocity script macros via the request (URL parameter) using the `XWikiServerClassSheet` if the user has view access to this sheet and another page that has been saved with programming rights, a standard condition on a public read-only XWiki installation or a private XWiki installation where the user has an account. This allows arbitrary Groovy/Python/Velocity code execution which allows bypassing all rights checks and thus both modification and disclosure of all content stored in the XWiki installation. Also, this could be used to impact the availability of the wiki. On current versions (e.g., 14.3), this can be triggered by opening the URL `/xwiki/bin/view/Main/?sheet=XWiki.XWikiServerClassSheet&form_token=<form_token>&action=delete&domain=foo%22%2F%7D%7D%7B%7Basync%20async%3D%22true%22%20cached%3D%22false%22%20context%3D%22doc.reference%22%7D%7D%7B%7Bgroovy%7D%7Dprintln(%22hello%20from%20groovy!%2...