deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-3mv5-343c-w2qg
Package: zerocopy (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: >= 0.2.2, < 0.2.9
Patched in: 0.2.9

Summary: Ref methods into_ref, into_mut, into_slice, and into_slice_mut are unsound when used with cell::Ref or cell::RefMut

Details:
*This advisory is also published as [RUSTSEC-2023-0074](https://rustsec.org/advisories/RUSTSEC-2023-0074.html).*

The `Ref` methods `into_ref`, `into_mut`, `into_slice`, and `into_slice_mut` are unsound and may allow safe code to exhibit undefined behavior when used with `Ref<B, T>` where `B` is [`cell::Ref`](https://doc.rust-lang.org/core/cell/struct.Ref.html) or [`cell::RefMut`](https://doc.rust-lang.org/core/cell/struct.RefMut.html). Note that these methods remain sound when used with `B` types other than `cell::Ref` or `cell::RefMut`.

See https://github.com/google/zerocopy/issues/716 for a more in-depth analysis.

The current plan is to yank the affected versions soon. See https://github.com/google/zerocopy/issues/679 for more detail.
GitHub Security Advisory: GHSA-x5fr-7hhj-34j3
Package: surrealdb (RUST)
Severity: HIGH (CVSS 8.8)
Vulnerable versions: < 1.0.1
Patched in: 1.0.1

Summary: Full Table Permissions by Default

Details:
Default table permissions in SurrealDB were `FULL` instead of `NONE`. This would lead to tables having `FULL` permissions for `SELECT`, `CREATE`, `UPDATE` and `DELETE` unless some other permissions were specified via the `PERMISSIONS` clause.

We have decided to treat this behaviour as a vulnerability due to its security implications, especially considering the lack of specific documentation and potential for confusion due to the `INFO FOR DB` statement previously not displaying default permissions. Treating it as a bug fix provides justification for a change in default behavior outside of a major release.

### Impact

Any client authorized to query data in a SurrealDB instance will have full access to any tables that were defined with no explicit permissions and that are within its authorization scope (i.e. namespace or database), including creating, reading, updating and deleting data. This is specially relevant for SurrealDB instances allowing guest access with publicly exposed interfaces (e.g. HTTP REST API or WebSocket API), since a remote unauthenticated user may gain full access to any tables that were defined without any explicit permissions. Tables that were defined with explicit permissions using the `PERMISSIONS` clause are not affected.

### Patches

- Version `1.0.1` includes a patch for this specific issue. Later releases will also include the patch.
- Version `1.1.0-beta.1` and latest nightly releases already include the patch for this issue.

In patched versions:

- Tables defined after the patch without explicit permissions have `NONE` permissions.
- Table permissions are always explicitly displayed with the `INFO FOR DB` statement.

### Workarounds

In unpatched versions, this issue can be resolved by explicitly defining table permissions as shown in the following examples:

```sql
-- INSECURE EXAMPLE
-- DEFINE TABLE insecure;
-- SECURE EXAMPLE 1
DEFINE TABLE secure PERMISSIONS NONE;
-- SECURE EXAMPLE 2
DEFINE TABLE secure PERMISSIONS FOR SELECT, CREATE, UPDATE, DELETE NONE;
-- SECURE EXAMPLE 3
DEFINE TABLE secure PERMISSIONS FOR
  SELECT WHERE user = $auth.id,
  CREATE, UPDATE, DELETE NONE;
-- SECURE EXAMPLE 4
DEFINE TABLE secure PERMISSIONS
  FOR select WHERE published = true OR user = $auth.id
  FOR create, update WHERE user = $auth.id
  FOR delete WHERE user = $auth.id OR $auth.admin = true;
```

### References

- https://github.com/surrealdb/surrealdb/pull/3074
- https://github.com/surrealdb/surrealdb/pull/3083
- https://github.com/surrealdb/surrealdb/pull/3125
- https://docs.surrealdb.com/docs/surrealql/statements/define/table/
- https://docs.surrealdb.com/docs/security/capabilities#guest-access
GitHub Security Advisory: GHSA-w3vp-jw9m-f9pm
Package: quiche (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 0.15.0, < 0.19.1
Patched in: 0.19.1

Summary: Unbounded queuing of path validation messages in cloudflare-quiche

Details:
### Impact
quiche v. 0.15.0 through 0.19.0 was discovered to be vulnerable to unbounded queuing of path validation messages, which could lead to excessive resource consumption.

QUIC path validation ([RFC 9000 Section 8.2](https://datatracker.ietf.org/doc/html/rfc9000#section-8.2)) requires that the recipient of a PATH_CHALLENGE frame responds by sending a PATH_RESPONSE. An unauthenticated remote attacker can exploit the vulnerability by sending PATH_CHALLENGE frames and manipulating the connection (e.g. by restricting the peer's congestion window size) so that PATH_RESPONSE frames can only be sent at the slower rate than they are received, leading to storage of path validation data in an unbounded queue.

### Patches
Quiche versions greater than 0.19.0 address this problem.

### References
[CVE-2023-6193](https://www.cve.org/CVERecord?id=CVE-2023-6193)
[RFC 9000 Section 8.2](https://datatracker.ietf.org/doc/html/rfc9000#section-8.2)
GitHub Security Advisory: GHSA-4mq4-7rw3-vm5j
Package: wasmer-cli (RUST)
Severity: HIGH (CVSS 8.4)
CWE: CWE-284: Improper Access Control
Vulnerable versions: >= 3.0.0, < 4.2.4
Patched in: 4.2.4

Summary: Wasmer filesystem sandbox not enforced

Details:
### Summary
As of Wasmer version v4.2.3, Wasm programs can access the filesystem outside of the sandbox.

### Details
https://github.com/wasmerio/wasmer/issues/4267

### PoC
A minimal Rust program:

```
fn main() {
    let f = std::fs::OpenOptions::new()
        .write(true)
        .create_new(true)
        .open("abc")
        .unwrap();
}
```

This should be compiled with `cargo build --target wasm32-wasi`. The compiled program, when run with wasmer WITHOUT `--dir`, can still create a file in the working directory.

### Impact
Service providers running untrusted Wasm code on Wasmer can unexpectedly expose the host filesystem.
GitHub Security Advisory: GHSA-7787-p7x6-fq3j
Package: candid (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop'), CWE-1288: Improper Validation of Consistency within Input
Vulnerable versions: >= 0.9.0, < 0.9.10
Patched in: 0.9.10

Summary: Candid infinite decoding loop through specially crafted payload

Details:
### Impact

The Candid library causes a Denial of Service while parsing a specially crafted payload with `empty` data type. For example, if the payload is `record { * ; empty }` and  the canister interface expects `record { * }` then the rust candid decoder treats `empty` as an extra field required by the type.  The problem with type `empty` is that the candid rust library wrongly categorizes `empty` as a recoverable error when skipping the field and thus causing an infinite decoding loop. 

Canisters using affected versions of candid are exposed to denial of service by causing the decoding to run indefinitely until the canister traps due to reaching maximum instruction limit per execution round. Repeated exposure to the payload will result in degraded performance of the canister.

For asset canister users, `dfx` versions `>= 0.14.4` to `<= 0.15.2-beta.0` ships asset canister with an affected version of candid.

#### Unaffected 
- Rust canisters using candid `< 0.9.0` or `>= 0.9.10` 
- Rust canister interfaces of type other than `record { * }`
- Motoko based canisters
- dfx (for asset canister) `<= 0.14.3` or `>= 0.15.2`


### Patches

The issue has been patched in `0.9.10`. All rust based canisters on candid versions `>= 0.9.0` must upgrade their candid versions to `>= 0.9.10` and deploy their canisters to mainnet as soon as possible. 

### Workarounds

There is no workaround for canisters using the affected versions of candid other than upgrading to patched version.

### References
-  [dfinity/candid/pull/478](https://github.com/dfinity/candid/pull/478)
-  [Candid Library Reference](https://internetcomputer.org/docs/current/references/candid-ref)
-  [Candid Specification](https://github.com/dfinity/candid/blob/master/spec/Candid.md)
-  [Internet Computer Specification](https://internetcomputer.org/docs/current/references/ic-interface-spec)
GitHub Security Advisory: GHSA-4grx-2x9w-596c
Package: rsa (RUST)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-385: Covert Timing Channel
Vulnerable versions: <= 0.9.6
Patched in: unpatched

Summary: Marvin Attack: potential key recovery through timing sidechannels

Details:
The [Marvin Attack] is a timing sidechannel vulnerability which allows performing RSA decryption and signing operations as an attacker with the ability to observe only the time of the decryption operation performed withthe private key.

A recent survey of RSA implementations found that the Rust `rsa` crate is one of many implementations vulnerable to this attack.

No fixed version is available at this time.

[Marvin Attack]: https://people.redhat.com/~hkario/marvin/
GitHub Security Advisory: GHSA-c38w-74pg-36hr
Package: rsa (RUST)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-203: Observable Discrepancy, CWE-385: Covert Timing Channel
Vulnerable versions: <= 0.9.6
Patched in: unpatched

Summary: Marvin Attack: potential key recovery through timing sidechannels

Details:
### Impact
Due to a non-constant-time implementation, information about the private key is leaked through timing information which is observable over the network. An attacker may be able to use that information to recover the key.

### Patches
No patch is yet available, however work is underway to migrate to a fully constant-time implementation.

### Workarounds
The only currently available workaround is to avoid using the `rsa` crate in settings where attackers are able to observe timing information, e.g. local use on a non-compromised computer is fine.

### References
This vulnerability was discovered as part of the "Marvin Attack", which revealed several implementations of RSA including OpenSSL had not properly mitigated timing sidechannel attacks.

- https://rustsec.org/advisories/RUSTSEC-2023-0071.html
- https://people.redhat.com/~hkario/marvin/
- https://github.com/RustCrypto/RSA/issues/19
GitHub Security Advisory: GHSA-5844-q3fc-56rh
Package: pubnub (RUST)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-331: Insufficient Entropy
Vulnerable versions: < 0.4.0
Patched in: 0.4.0

Summary: pubnub Insufficient Entropy vulnerability

Details:
Versions of the package pubnub before 7.4.0; all versions of the package com.pubnub:pubnub; versions of the package pubnub before 6.19.0; all versions of the package github.com/pubnub/go; versions of the package github.com/pubnub/go/v7 before 7.2.0; versions of the package pubnub before 7.3.0; versions of the package pubnub/pubnub before 6.1.0; versions of the package pubnub before 5.3.0; versions of the package pubnub before 0.4.0; versions of the package pubnub/c-core before 4.5.0; versions of the package com.pubnub:pubnub-kotlin before 7.7.0; versions of the package pubnub/swift before 6.2.0; versions of the package pubnub before 5.2.0; versions of the package pubnub before 4.3.0 are vulnerable to Insufficient Entropy via the getKey function, due to inefficient implementation of the AES-256-CBC cryptographic algorithm. The provided encrypt function is less secure when hex encoding and trimming are applied, leaving half of the bits in the key always the same for every encoded message or file.

**Note:**

In order to exploit this vulnerability, the attacker needs to invest resources in preparing the attack and brute-force the encryption.
GitHub Security Advisory: GHSA-pjrj-h4fg-6gm4
Package: tokio-boring (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-401: Missing Release of Memory after Effective Lifetime, CWE-404: Improper Resource Shutdown or Release
Vulnerable versions: = 4.0.0
Patched in: 4.1.0

Summary: tokio-boring vulnerable to resource exhaustion via memory leak

Details:
### Impact
The tokio-boring library in version 4.0.0 is affected by a memory leak issue that can lead to excessive resource consumption and potential DoS by resource exhaustion. The `set_ex_data` function used by the library did not deallocate memory used by pre-existing data in memory each time after completing a TLS connection causing the program to consume more resources with each new connection.

### Patches
The issue is fixed in version 4.1.0 of tokio-boring.

### References
[CVE-2023-6180 at cve.org](https://www.cve.org/CVERecord?id=CVE-2023-6180)
GitHub Security Advisory: GHSA-wj7f-468m-6mv8
Package: birdcage (RUST)
Severity: MODERATE (CVSS 4.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 0.7.0
Patched in: 0.7.0

Summary: Environment variables still accessible through /proc

Details:
### Impact

Environment variables can be read from procfs unless a new process is started.

### PoC

```
use birdcage::{Birdcage, Sandbox};
use std::{env, fs};

fn main() {
    Birdcage::new().lock().unwrap();

    assert_eq!(env::var_os("SECRET"), None);

    let environ = fs::read_to_string("/proc/self/environ").unwrap();
    assert!(!environ.contains("SECRET"), "ENVIRON CONTAINS SECRET:\n{environ}");
}
```

```
$  SECRET=test cargo run
thread 'main' panicked at src/main.rs:10:5:
ENVIRON CONTAINS SECRET:
 [truncated]
 ```

### Possible Solutions

The simplest solution would be relying on the ptrace isolation and **always** spawning a new process by changing birdcage's API to create a new command. With an additional PID namespace the guarantees could be even further reinforced.
GitHub Security Advisory: GHSA-xphf-cx8h-7q9g
Package: openssl (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.10.29, < 0.10.60
Patched in: 0.10.60

Summary: `openssl` `X509StoreRef::objects` is unsound

Details:
This function returned a reference into an OpenSSL datastructure, but there was no way to ensure OpenSSL would not mutate the datastructure behind one's back.

Use of this function should be replaced with `X509StoreRef::all_certificates`.
GitHub Security Advisory: GHSA-48m6-wm5p-rr6h
Package: self_cell (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: >= 1.0.0, < 1.0.2
Patched in: 1.0.2

Summary: Insufficient covariance check makes self_cell unsound

Details:
All public versions prior to `1.02` used an insufficient check to ensure that users correctly marked the dependent type as either `covariant` or `not_covariant`. This allowed users to mark a dependent as covariant even though its type was not covariant but invariant, for certain invariant types involving trait object lifetimes. One example for such a dependent type is `type Dependent<'a> = RefCell<Box<dyn fmt::Display + 'a>>`. Such a type allowed unsound usage in purely safe user code that leads to undefined behavior. The patched versions now produce a compile time error if such a type is marked as `covariant`.
GitHub Security Advisory: GHSA-48m6-wm5p-rr6h
Package: self_cell (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: < 0.10.3
Patched in: 0.10.3

Summary: Insufficient covariance check makes self_cell unsound

Details:
All public versions prior to `1.02` used an insufficient check to ensure that users correctly marked the dependent type as either `covariant` or `not_covariant`. This allowed users to mark a dependent as covariant even though its type was not covariant but invariant, for certain invariant types involving trait object lifetimes. One example for such a dependent type is `type Dependent<'a> = RefCell<Box<dyn fmt::Display + 'a>>`. Such a type allowed unsound usage in purely safe user code that leads to undefined behavior. The patched versions now produce a compile time error if such a type is marked as `covariant`.
GitHub Security Advisory: GHSA-wvc4-j7g5-4f79
Package: nats (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: >= 0.9.0, <= 0.24.0
Patched in: 0.24.1

Summary: NATS TLS certificate common name validation bypass

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

A fix for the `nats` crate hasn't been released yet. Since the `nats` crate is going to be deprecated anyway, consider switching to `async-nats` `>= 0.29` which already fixed this vulnerability.

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
9. The client has been fooled by the MitM proxy into accepting the attacker-controlled certificate
GitHub Security Advisory: GHSA-475v-pq2g-fp9g
Package: s2n-quic (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: <= 1.30.0
Patched in: 1.31.0

Summary: s2n-quic potential denial of service via crafted stream frames

Details:
### Impact
An issue in s2n-quic could result in unnecessary resource utilization when peers open streams beyond advertised limits.

Impacted versions: <= v1.30.0.

### Patches
The patch is included in v1.31.0 [1].

### Workarounds
There is no workaround. Applications using s2n-quic should upgrade to the most recent release of s2n-quic.

If you have any questions or comments about this advisory, we ask that you contact AWS Security via our vulnerability reporting page [2] or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.

[1] https://github.com/aws/s2n-quic/releases/tag/v1.31.0
[2] https://aws.amazon.com/security/vulnerability-reporting
GitHub Security Advisory: GHSA-j57r-4qw6-58r3
Package: rusty-paseto (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: <= 0.5.0
Patched in: 0.6.0

Summary: rusty_paseto vulnerable to private key extraction due to ed25519-dalek dependency

Details:
## Impact

The vulnerability, known as RUSTSEC-2022-0093, impacts the `ed25519-dalek` crate, which is a dependency of the `rusty-paseto` crate. This issue arises from a "Double Public Key Signing Function Oracle Attack" affecting versions of `ed25519-dalek` prior to v2.0. These versions expose an unsafe API for serializing and deserializing 64-byte keypairs that include both private and public keys, creating potential for certain attacks. `d25519-dalek` users utilizing these serialization and deserialization functions directly could potentially be impacted. 

## Patches

The vulnerability within the `ed25519-dalek` crate has been addressed in version 2.0. `rusty-paseto` has addressed it in release v0.6.0. 

## Workarounds

Users are recommended to upgrade to v0.6.0 of `rusty-paseto`. However, users should still ensure that their key serialization and deserialization practices are secure and avoid any practices that could lead to key exposure.

## References

More information about RUSTSEC-2022-0093 can be found in the [RustSec Advisory Database](https://rustsec.org/advisories/RUSTSEC-2022-0093.html). Updates and details regarding the upcoming release of `rusty-paseto` will be documented in the project's [releases](https://github.com/your-repo/rusty-paseto/releases) and [changelog](https://github.com/your-repo/rusty-paseto/blob/main/CHANGELOG.md).  This issue was first reported by Dependabot on 2023-08-15. The source was reviewed by @rrrodzilla at that time and a determination was made that the vulnerability low harm to existing users due to the strongly typed nature of keys provided by the rusty-paseto API. @techport-om reported the vulnerability to the repository by discovering during a `cargo-audit` run on 2023-11-05 and opened [issue 28](https://github.com/rrrodzilla/rusty_paseto/issues/28). This advisory was created at that time to notify existing users.
GitHub Security Advisory: GHSA-jq66-xh47-j9f3
Package: failure (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')
Vulnerable versions: <= 0.1.8
Patched in: unpatched

Summary: Type confusion if __private_get_type_id__ is overriden

Details:
An issue was discovered in the failure crate through 0.1.5 for Rust. It may introduce "compatibility hazards" in some applications, and has a type confusion flaw when downcasting. NOTE: This vulnerability only affects products that are no longer supported by the maintainer. NOTE: This may overlap CVE-2019-25010.
GitHub Security Advisory: GHSA-5873-6fwq-463f
Package: stellar-strkey (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-248: Uncaught Exception
Vulnerable versions: < 0.0.8
Patched in: 0.0.8

Summary: stellar-strkey vulnerable to panic in SignedPayload::from_payload

Details:
### Impact
Panic vulnerability when a specially crafted payload is used. 
This is because of the following calculation:
```rust
inner_payload_len + (4 - inner_payload_len % 4) % 4
```
If `inner_payload_len` is `0xffffffff`, `(4 - inner_payload_len % 4) % 4 = 1` so
```rust
inner_payload_len + (4 - inner_payload_len % 4) % 4 = u32::MAX + 1
```
which overflow.

### Patches
Check that `inner_payload_len` is not above 64 which should never be the case.
Patched in version 0.0.8

### Workarounds
Sanitize input payload before it is passed to the vulnerable function so that bytes in `payload[32..32+4]` and parsed as a `u32` is not above 64.

### References
GitHub issue #58
GitHub Security Advisory: GHSA-6878-6wc2-pf5h
Package: cocoon (RUST)
Severity: MODERATE (CVSS 4.5)
Vulnerable versions: < 0.4.0
Patched in: 0.4.0

Summary: Sequential calls of encryption API (`encrypt`, `wrap`, and `dump`) result in nonce reuse

Details:
**Problem**: Trying to create a new encrypted message with the same cocoon object generates the same ciphertext. It mostly affects `MiniCocoon` and `Cocoon` objects with custom seeds and RNGs (where `StdRng` is used under the hood).

**Note**: The issue does **NOT** affect objects created with **`Cocoon::new`** which utilizes `ThreadRng`.

**Cause**: `StdRng` produces the same nonce because `StdRng::clone` resets its state.

**Measure**: Make encryption API mutable (`encrypt`, `wrap`, and `dump`).

**Workaround**: Create a new cocoon object with a new **seed** per each encryption.

## How to Reproduce

```rust
let cocoon = MiniCocoon::from_password(b"password", &[1; 32]);
let mut data1 = "my secret data".to_owned().into_bytes();
let _ = cocoon.encrypt(&mut data1)?;

let mut data2 = "my secret data".to_owned().into_bytes();
let _ = cocoon.encrypt(&mut data2)?;

// data1: [23, 217, 251, 151, 179, 62, 85, 15, 253, 92, 192, 112, 200, 52]
// data2: [23, 217, 251, 151, 179, 62, 85, 15, 253, 92, 192, 112, 200, 52]
```

## Workaround

For `cocoon <= 0.3.3`, create a new cocoon with a different **seed** per each `encrypt`/`wrap`/`dump` call.

```rust
let cocoon = MiniCocoon::from_password(b"password", &[1; 32]);
let mut data1 = "my secret data".to_owned().into_bytes();
let _ = cocoon.encrypt(&mut data1)?;

// Another seed: &[2; 32].
let cocoon = MiniCocoon::from_password(b"password", &[2; 32]);
let mut data2 = "my secret data".to_owned().into_bytes();
let _ = cocoon.encrypt(&mut data2)?;

// data1: [23, 217, 251, 151, 179, 62, 85, 15, 253, 92, 192, 112, 200, 52]
// data2: [53, 223, 209, 96, 130, 99, 209, 108, 83, 189, 123, 81, 19, 1]
```