ghsa

Ward Beullens found a practical key-recovery attack against Rainbow. The level I parametersets are removed from liboqs starting from version `0.7.2`. Find the scientific details in [Breaking Rainbow Takes a Weekend on a Laptop](https://eprint.iacr.org/2022/214). This means all the `oqs::sig::Algorithm::RainbowI*` variants are insecure.

# Vulnerability Report ## Impact Smart contract applications that make use of the `selfdestruct` functionality and their end-users. ## Classification The vulnerability has been classified as `high` with a CVSS score of `8.2`. It has the potential to create a denial-of-service to all contracts that can invoke the [`selfdestruct`](https://ethereum.stackexchange.com/questions/315/why-are-selfdestructs-used-in-contract-programming#347) function to destroy a smart contract. ## Users Impacted Due to the successfully coordinated security vulnerability disclosure, no smart contracts were impacted through the use of this vulnerability. Smart contract states and storage values are not affected by this vulnerability. User funds and balances are safe. ## Disclosure In Ethermint running versions before `v0.17.2`, the contract `selfdestruct` invocation permanently removes the corresponding bytecode from the internal database storage. However, due to a bug in the [`DeleteAccount`](https://gi...

### Impact This vulnerability may allow [SameSite Attackers](https://canitakeyoursubdomain.name/) to bypass the [CodeIgniter4 CSRF protection](https://codeigniter4.github.io/userguide/libraries/security.html) mechanism with CodeIgniter Shield. For this attack to succeed, the attacker must have direct (or indirect, e.g., XSS) control over a subdomain site (e.g., `https://a.example.com/`) of the target site (e.g., `http://example.com/`). This vulnerability exists whether `Config\Security::$csrfProtection` is `'cookie'` or `'session'`. It is also exploitable whether `Config\Security::$regenerate` is `true` or `false`. ### Patches Upgrade to **CodeIgniter v4.2.3 or later** and **Shield v1.0.0-beta.2 or later**. ### Workarounds Do all of the following: - set `Config\Security::$csrfProtection` to `'session'` - remove old session data right after login (immediately after ID and password match) - regenerate CSRF token right after login (immediately after ID and password match) ### Referen...

### Impact `=< [email protected]` users are vulnerable to _CRLF Injection_ on headers when using unsanitized input as request headers, more specifically, inside the `content-type` header. Example: ``` import { request } from 'undici' const unsanitizedContentTypeInput = 'application/json\r\n\r\nGET /foo2 HTTP/1.1' await request('http://localhost:3000, { method: 'GET', headers: { 'content-type': unsanitizedContentTypeInput }, }) ``` The above snippet will perform two requests in a single `request` API call: 1) `http://localhost:3000/` 2) `http://localhost:3000/foo2` ### Patches This issue was patched in Undici v5.8.1 ### Workarounds Sanitize input when sending content-type headers using user input. ## For more information If you have any questions or comments about this advisory: - Open an issue in [undici repository](https://github.com/nodejs/undici/issues) - To make a report, follow the [SECURITY](https://github.com/nodejs/node/blob/HEAD/SECURITY.md) document...

**Summary** As part of a Kubevirt audit performed by NCC group, a finding dealing with systemic lack of path sanitization which leads to a path traversal was identified. Google tested the exploitability of the paths in the audit report and identified that when combined with another vulnerability one of the paths leads to an arbitrary file read on the host from the VM. The read operations are limited to files which are publicly readable or which are readable for UID 107 or GID 107. /proc/self/<> is not accessible. **Severity** Moderate - The vulnerability is proven to exist in an open source version of KubeVirt by NCC Group while being combined with Systemic Lack of Path Sanitization, which leads to Path traversal. **Proof of Concept** The initial VMI specifications can be written as such to reproduce the issue: ``` apiVersion: kubevirt.io/v1 kind: VirtualMachineInstance metadata: name: vmi-fedora spec: domain: devices: disks: - disk: bus: virtio ...

## Impact The `core.exportVariable` function uses a well known delimiter that attackers can use to break out of that specific variable and assign values to other arbitrary variables. Workflows that write untrusted values to the `GITHUB_ENV` file may cause the path or other environment variables to be modified without the intention of the workflow or action author. ## Patches Users should upgrade to `@actions/core v1.9.1`. ## Workarounds If you are unable to upgrade the `@actions/core` package, you can modify your action to ensure that any user input does not contain the delimiter `_GitHubActionsFileCommandDelimeter_` before calling `core.exportVariable`. ## References [More information about setting-an-environment-variable in workflows](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-environment-variable) If you have any questions or comments about this advisory: * Open an issue in [`actions/toolkit`](https://github.com/actions...

Wouter Castryck and Thomas Decru presented an efficient key recovery attack on the SIDH protocol. As a result, the secret key of SIKEp751 can be recovered in a matter of hours. The SIKE and SIDH schemes will be removed from oqs 0.7.2. [An efficient key recovery attack on SIDH (preliminary version)](https://eprint.iacr.org/2022/975)

### Impact The functions `ECDSA.recover` and `ECDSA.tryRecover` are vulnerable to a kind of signature malleability due to accepting EIP-2098 compact signatures in addition to the traditional 65 byte signature format. This is only an issue for the functions that take a single `bytes` argument, and not the functions that take `r, v, s` or `r, vs` as separate arguments. The potentially affected contracts are those that implement signature reuse or replay protection by marking the signature itself as used rather than the signed message or a nonce included in it. A user may take a signature that has already been submitted, submit it again in a different form, and bypass this protection. ### Patches The issue has been patched in 4.7.3. ### For more information If you have any questions or comments about this advisory, or need assistance deploying a fix, email us at [[email protected]](mailto:[email protected]).

### Impact `undici` is vulnerable to SSRF (Server-side Request Forgery) when an application takes in **user input** into the `path/pathname` option of `undici.request`. If a user specifies a URL such as `http://127.0.0.1` or `//127.0.0.1` ```js const undici = require("undici") undici.request({origin: "http://example.com", pathname: "//127.0.0.1"}) ``` Instead of processing the request as `http://example.org//127.0.0.1` (or `http://example.org/http://127.0.0.1` when `http://127.0.0.1 is used`), it actually processes the request as `http://127.0.0.1/` and sends it to `http://127.0.0.1`. If a developer passes in user input into `path` parameter of `undici.request`, it can result in an _SSRF_ as they will assume that the hostname cannot change, when in actual fact it can change because the specified path parameter is combined with the base URL. ### Patches This issue was fixed in `[email protected]`. ### Workarounds The best workaround is to validate user input before passing it to the...

### Impact The default landing page contained HTML to display a sample `curl` command which is made visible if the full landing page bundle could not be fetched from Apollo's CDN. The server's URL is directly interpolated into this command inside the browser from `window.location.href`. On some older browsers such as IE11, this value is not URI-encoded. On such browsers, opening a malicious URL pointing at an Apollo Router could cause execution of attacker-controlled JavaScript. This only affects Apollo Server with the [default landing page](https://www.apollographql.com/docs/apollo-server/api/plugin/landing-pages/) enabled. Old browsers visiting your server may be affected if ANY of these apply: - You do not pass any landing page plugin to the `plugins` option of `new ApolloServer`. - You pass `ApolloServerPluginLandingPageLocalDefault()` or `ApolloServerPluginLandingPageProductionDefault()` to the `plugins` option of `new ApolloServer`. Browsers visiting your server are NOT affect...