#perl

If we know a user is legitimate, then why would we want to make their user experience more challenging?

Ubuntu Security Notice 5616-1 - Asaf Modelevsky discovered that the Intel 10GbE PCI Express Ethernet driver for the Linux kernel performed insufficient control flow management. A local attacker could possibly use this to cause a denial of service. Moshe Kol, Amit Klein and Yossi Gilad discovered that the IP implementation in the Linux kernel did not provide sufficient randomization when calculating port offsets. An attacker could possibly use this to expose sensitive information.

The NEX-Forms WordPress plugin before 7.9.7 does not properly sanitise and escape user input before using it in SQL statements, leading to SQL injections. The attack can be executed by anyone who is permitted to view the forms statistics chart, by default administrators, however can be configured otherwise via the plugin settings.

Nextcloud android is the official Android client for the Nextcloud home server platform. Internal paths to the Nextcloud Android app files are not properly protected. As a result access to internal files of the from within the Nextcloud Android app is possible. This may lead to a leak of sensitive information in some cases. It is recommended that the Nextcloud Android app is upgraded to 3.21.0. There are no known workarounds for this issue.

Moby is an open-source project created by Docker to enable software containerization. A bug was found in Moby (Docker Engine) where supplementary groups are not set up properly. If an attacker has direct access to a container and manipulates their supplementary group access, they may be able to use supplementary group access to bypass primary group restrictions in some cases, potentially gaining access to sensitive information or gaining the ability to execute code in that container. This bug is fixed in Moby (Docker Engine) 20.10.18. Users should update to this version when it is available. Running containers should be stopped and restarted for the permissions to be fixed. For users unable to upgrade, this problem can be worked around by not using the `"USER $USERNAME"` Dockerfile instruction. Instead by calling `ENTRYPOINT ["su", "-", "user"]` the supplementary groups will be set up properly. Thanks to Steven Murdoch for reporting this issue. ---- ### Impact If an attacker has d...

indy-node is the server portion of Hyperledger Indy, a distributed ledger purpose-built for decentralized identity. ### Impact An attacker can max out the number of client connections allowed by the ledger that was deployed using guidance provided in the indy-node repository, leaving the ledger unable to be used for its intended purpose. The ledger content will not be impacted by the attack, and the ledger will resume servicing valid client requests after the attack. ### Mitigations This attack exploits the trade-off between resilience and availability. Any protection against abusive client connections will also prevent the network being accessed by certain legitimate users. As a result, validator nodes must tune their firewall rules to ensure the right trade-off for their network's expected users. The guidance previously provided enabled a low-cost DDoS attack. The [guidance to network operators for the use of firewall rules](https://github.com/hyperledger/indy-node/blob/main/do...

### Impact Due to missing canonicalization when `readDir` is called recursively, it was possible to display directory listings outside of the defined `fs` scope. This required a crafted symbolic link or junction folder inside an allowed path of the `fs` scope. No arbitrary file content could be leaked. ### Patches The issue has been resolved in https://github.com/tauri-apps/tauri/pull/5123 and the implementation now properly checks if the requested (sub) directory is a symbolic link outside of the defined `scope`. ### Workarounds Disable the `readDir` endpoint in the `allowlist` inside the `tauri.conf.json`. ### For more information This issue was initially reported by [martin-ocasek]( https://github.com/martin-ocasek) in [#4882](https://github.com/tauri-apps/tauri/issues/4882). If you have any questions or comments about this advisory: * Open an issue in [tauri](https://github.com/tauri-apps/tauri) * Email us at [[email protected]](mailto:[email protected])

### Observation When handling dependencies that come from a Git repository instead of a registry, Poetry uses various commands, such as `git clone`. These commands are being constructed using user input (e.g. the repository URL). When building the commands, Poetry correctly avoids Command Injection vulnerabilities by passing an array of arguments instead of a command string. However, there is the possibility that a user input starts with a dash (`-`) and is therefore treated as an optional argument instead of a positional one. This can lead to Code Execution because some of the commands have options that can be leveraged to run arbitrary executables. To clone a repository, Poetry builds a git clone command, but fails to validate or sanitize the repository location properly: [`poetry/core/vcs/git.py`](https://github.com/python-poetry/poetry-core/blob/ad33bc2f92be03dc5b31a666664903c439fb1173/poetry/core/vcs/git.py#L207): ```python def clone(self, repository: str, dest: Path) -> str: ...

### Impact The tags document `Main.Tags` in XWiki didn't sanitize user inputs properly, allowing users with view rights on the document (default in a public wiki or for authenticated users on private wikis) to execute arbitrary Groovy, Python and Velocity code with programming rights. This 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. Some versions of XWiki XML-escaped the tag (e.g., version 3.1) but this isn't a serious limitation as string literals can be delimited by `/` in Groovy and `<` and `>` aren't necessary, e.g., to elevate privileges of the current user. On XWiki versions before 13.10.4 and 14.2, this can be combined with the [authentication bypass using the login action](https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-8h89-34w2-jpfm), meaning that no rights are required to perform the attack. The following URL dem...

### Impact All rights checks that would normally prevent a user from viewing a document on a wiki can be bypassed using the login action and directly specified templates. This exposes title, content and comments of any document and properties of objects (class and property name must be known, though). This is also exploitable on [private wikis](https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Access%20Rights/#HPrivateWiki). ### Patches This has been patched in versions 14.2 and 13.10.4 by properly checking view rights before loading documents and disallowing non-default templates in the login, registration and skin action. ### Workarounds It would be possible to protect all templates individually by adding code to check access rights first, but due to the number of templates and the fact that some of them need to be used without view rights, this seems impractical. ### References * https://jira.xwiki.org/browse/XWIKI-19549 * https://jira.xwiki.org/browse/XWIKI-18602 ##...