deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-c2hf-vcmr-qjrf
Package: object_store (RUST)
Severity: MODERATE (CVSS 3.8)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: >= 0.5.0, < 0.10.2
Patched in: 0.10.2

Summary: Apache Arrow Rust Object Store: AWS WebIdentityToken exposure in log files

Details:
Exposure of temporary credentials in logs in Apache Arrow Rust Object Store (`object_store` crate), version 0.10.1 and earlier on all platforms using AWS WebIdentityTokens. 

On certain error conditions, the logs may contain the OIDC token passed to  AssumeRoleWithWebIdentity https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html . This allows someone with access to the logs to impersonate that identity, including performing their own calls to AssumeRoleWithWebIdentity, until the OIDC token expires. Typically OIDC tokens are valid for up to an hour, although this will vary depending on the issuer.

Users are recommended to use a different AWS authentication mechanism, disable logging or upgrade to version 0.10.2, which fixes this issue.

Details:

When using AWS WebIdentityTokens with the object_store crate, in the event of a failure and automatic retry, the underlying reqwest error, including the full URL with the credentials, potentially in the parameters, is written to the logs. 

Thanks to Paul Hatcherian for reporting this vulnerability
GitHub Security Advisory: GHSA-q445-7m23-qrmw
Package: openssl (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: < 0.10.66
Patched in: 0.10.66

Summary: openssl's `MemBio::get_buf` has undefined behavior with empty buffers

Details:
Previously, `MemBio::get_buf` called `slice::from_raw_parts` with a null-pointer, which violates the functions invariants, leading to undefined behavior. In debug builds this would produce an assertion failure. This is now fixed.
GitHub Security Advisory: GHSA-4qg4-cvh2-crgg
Package: matrix-sdk-crypto (RUST)
Severity: MODERATE (CVSS 4.8)
CWE: CWE-287: Improper Authentication, CWE-863: Incorrect Authorization
Vulnerable versions: < 0.7.2
Patched in: 0.7.2

Summary: matrix-sdk-crypto's `UserIdentity::is_verified` not checking verification status of own user identity while performing the check

Details:
The `UserIdentity::is_verified()` method in the matrix-sdk-crypto crate before version 0.7.2 doesn't take into account the verification status of the user's own identity while performing the check and may as a result return a value contrary to what is implied by its name and documentation.

### Impact

If the method is used to decide whether to perform sensitive operations towards a user identity, a malicious homeserver could manipulate the outcome in order to make the identity appear trusted. This is not a typical usage of the method, which lowers the impact. The method itself is not used inside the `matrix-sdk-crypto` crate.

### Patches

The 0.7.2 release of the `matrix-sdk-crypto` crate includes a fix.

### Workarounds

None.
GitHub Security Advisory: GHSA-j8cm-g7r6-hfpq
Package: vodozemac (RUST)
Severity: MODERATE (CVSS 3.7)
CWE: CWE-208: Observable Timing Discrepancy
Vulnerable versions: < 0.7.0
Patched in: 0.7.0

Summary: vodozemac's usage of non-constant time base64 decoder could lead to leakage of secret key material

Details:
Versions before 0.7.0 of vodozemac use a non-constant time base64 implementation for importing key material for Megolm group sessions and `PkDecryption` Ed25519 secret keys. This flaw might allow an attacker to infer some information about the secret key material through a side-channel attack.

### Impact

The use of a non-constant time base64 implementation might allow an attacker to observe timing variations in the encoding and decoding operations of the secret key material. This could potentially provide insights into the underlying secret key material.

The impact of this vulnerability is considered low because exploiting the attacker is required to have access to high precision timing measurements, as well as repeated access to the base64 encoding or decoding processes.  Additionally, the estimated leakage amount is bounded and low according to the referenced paper.

### Patches

The patch is in commit 734b6c6948d4b2bdee3dd8b4efa591d93a61d272.

### Workarounds
None.

### References
A detailed description of the precise attack can be found at https://arxiv.org/abs/2108.04600. We kindly thank Soatok for pointing out this research to us.

### For more information
If you have any questions or comments about this advisory please email us at [security at matrix.org](mailto:security@matrix.org).
GitHub Security Advisory: GHSA-5xgj-pmjj-gw49
Package: risc0-zkvm (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: <= 1.0.2
Patched in: unpatched

Summary: RISC Zero zkVM notes on zero-knowledge

Details:
RISC Zero zkVM was designed from its inception to provide three main guarantees:
1. *Computational integrity*: that a given software program executed correctly.
2. *Succinctness*: that the proof of execution does not grow in relation to the program being executed.
3. *Zero Knowledge*: that details of the program execution are not visible within the proof of program execution.

Ulrich Habock and Al Kindi have released [new research] that indicates that several STARK implementations -including our RISC Zero zkVM- do not meet the requirements to assert the specific property of zero knowledge provably. 

While a vast majority of real-world applications that leverage RISC Zero zkVM or similar systems depend primarily on computational integrity and succinctness, a subset of applications critically depend on the privacy guarantees provided by zero-knowledge; and for those use cases, users are cautioned to understand the research and make informed decisions based on the risks outlined in using an impacted system.

Although the maintainers are not aware of any attacks that can take advantage of this potential weakness, they are working to proactively address this discovery as quickly as possible. 

[new research]: https://eprint.iacr.org/2024/1037
GitHub Security Advisory: GHSA-gh9f-6xm2-c4j2
Package: surrealdb-core (RUST)
Severity: MODERATE (CVSS 6.3)
CWE: CWE-287: Improper Authentication
Vulnerable versions: <= 1.5.0
Patched in: 1.5.1

Summary: SurrealDB vulnerable to Improper Authentication when Changing Databases as Scope User

Details:
Authentication would not be properly validated when an already authenticated scope user would use the `use` method or `USE` clause to switch working databases in a session. If there was a user record in the new database with identical record identifier as the original record that the user authenticated with in the original database, this could result in the user being able to perform actions under the identity of the unrelated user in the new database. This issue does not affect system users at any level.

By default, record identifiers are randomly generated with sufficient complexity to prevent the identifier collision required to trigger this issue. However, the issue may trigger in situations where multiple databases in the same SurrealDB instance are using explicitly defined or incremental record identifiers to identify users on an identically named table.

### Impact

Under the circumstances described above, a user who has an authenticated session as a scope user in a database could become authorized to query data under the identity of a specific scope user associated with an identical record identifier in a different database within the same SurrealDB instace if the `PERMISSIONS` clause would allow it due to relying exclusively on the `$auth` parameter, which would point to the impersonated user. The impact is limited to the single user with matching record identifier.

The impact of this issue is mitigated if the table `PERMISSIONS` clause explicitly checks for an scope that only exists in the specific database (e.g. `$scope = "production"`) or certain claims of the authentication token (e.g. `$token.email = "example@example.com"`), both of which would remain unchanged in the session of the authenticated user after changing databases. Permissions will default to `NONE` if there is no `PERMISSIONS` clause, which also mitigates this impact of this issue.

### Patches

- Version 1.5.4 and later are not affected by this issue.
- Version 2.0.0-alpha.6 and later will not be affected by this issue.

### Workarounds

Users unable to update may want to ensure that table `PERMISSIONS` clauses explicitly check that the `$scope` parameter matches a scope that is uniquely named across databases in the same SurrealDB instance. Ensuring that record identifiers for users are automatically generated or explicitly generated to be unique across databases may also be sufficient to mitigate this issue, as the `$auth` parameter will not link to any user record and any `PERMISSIONS` clauses restricting authorization based on the authenticated user should fail to successfully evaluate.

### References

- https://github.com/surrealdb/surrealdb/pull/4335
GitHub Security Advisory: GHSA-gh9f-6xm2-c4j2
Package: surrealdb (RUST)
Severity: MODERATE (CVSS 6.3)
CWE: CWE-287: Improper Authentication
Vulnerable versions: >= 2.0.0-alpha.1, <= 2.0.0-alpha.5
Patched in: 2.0.0-alpha.6

Summary: SurrealDB vulnerable to Improper Authentication when Changing Databases as Scope User

Details:
Authentication would not be properly validated when an already authenticated scope user would use the `use` method or `USE` clause to switch working databases in a session. If there was a user record in the new database with identical record identifier as the original record that the user authenticated with in the original database, this could result in the user being able to perform actions under the identity of the unrelated user in the new database. This issue does not affect system users at any level.

By default, record identifiers are randomly generated with sufficient complexity to prevent the identifier collision required to trigger this issue. However, the issue may trigger in situations where multiple databases in the same SurrealDB instance are using explicitly defined or incremental record identifiers to identify users on an identically named table.

### Impact

Under the circumstances described above, a user who has an authenticated session as a scope user in a database could become authorized to query data under the identity of a specific scope user associated with an identical record identifier in a different database within the same SurrealDB instace if the `PERMISSIONS` clause would allow it due to relying exclusively on the `$auth` parameter, which would point to the impersonated user. The impact is limited to the single user with matching record identifier.

The impact of this issue is mitigated if the table `PERMISSIONS` clause explicitly checks for an scope that only exists in the specific database (e.g. `$scope = "production"`) or certain claims of the authentication token (e.g. `$token.email = "example@example.com"`), both of which would remain unchanged in the session of the authenticated user after changing databases. Permissions will default to `NONE` if there is no `PERMISSIONS` clause, which also mitigates this impact of this issue.

### Patches

- Version 1.5.4 and later are not affected by this issue.
- Version 2.0.0-alpha.6 and later will not be affected by this issue.

### Workarounds

Users unable to update may want to ensure that table `PERMISSIONS` clauses explicitly check that the `$scope` parameter matches a scope that is uniquely named across databases in the same SurrealDB instance. Ensuring that record identifiers for users are automatically generated or explicitly generated to be unique across databases may also be sufficient to mitigate this issue, as the `$auth` parameter will not link to any user record and any `PERMISSIONS` clauses restricting authorization based on the authenticated user should fail to successfully evaluate.

### References

- https://github.com/surrealdb/surrealdb/pull/4335
GitHub Security Advisory: GHSA-gh9f-6xm2-c4j2
Package: surrealdb (RUST)
Severity: MODERATE (CVSS 6.3)
CWE: CWE-287: Improper Authentication
Vulnerable versions: <= 1.5.3
Patched in: 1.5.4

Summary: SurrealDB vulnerable to Improper Authentication when Changing Databases as Scope User

Details:
Authentication would not be properly validated when an already authenticated scope user would use the `use` method or `USE` clause to switch working databases in a session. If there was a user record in the new database with identical record identifier as the original record that the user authenticated with in the original database, this could result in the user being able to perform actions under the identity of the unrelated user in the new database. This issue does not affect system users at any level.

By default, record identifiers are randomly generated with sufficient complexity to prevent the identifier collision required to trigger this issue. However, the issue may trigger in situations where multiple databases in the same SurrealDB instance are using explicitly defined or incremental record identifiers to identify users on an identically named table.

### Impact

Under the circumstances described above, a user who has an authenticated session as a scope user in a database could become authorized to query data under the identity of a specific scope user associated with an identical record identifier in a different database within the same SurrealDB instace if the `PERMISSIONS` clause would allow it due to relying exclusively on the `$auth` parameter, which would point to the impersonated user. The impact is limited to the single user with matching record identifier.

The impact of this issue is mitigated if the table `PERMISSIONS` clause explicitly checks for an scope that only exists in the specific database (e.g. `$scope = "production"`) or certain claims of the authentication token (e.g. `$token.email = "example@example.com"`), both of which would remain unchanged in the session of the authenticated user after changing databases. Permissions will default to `NONE` if there is no `PERMISSIONS` clause, which also mitigates this impact of this issue.

### Patches

- Version 1.5.4 and later are not affected by this issue.
- Version 2.0.0-alpha.6 and later will not be affected by this issue.

### Workarounds

Users unable to update may want to ensure that table `PERMISSIONS` clauses explicitly check that the `$scope` parameter matches a scope that is uniquely named across databases in the same SurrealDB instance. Ensuring that record identifiers for users are automatically generated or explicitly generated to be unique across databases may also be sufficient to mitigate this issue, as the `$auth` parameter will not link to any user record and any `PERMISSIONS` clauses restricting authorization based on the authenticated user should fail to successfully evaluate.

### References

- https://github.com/surrealdb/surrealdb/pull/4335
GitHub Security Advisory: GHSA-74r5-g7vc-j2v2
Package: zerovec-derive (RUST)
Severity: MODERATE (CVSS 6.2)
CWE: CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Vulnerable versions: >= 0.10.0, < 0.10.3
Patched in: 0.10.3

Summary: zerovec-derive incorrectly uses `#[repr(packed)]`

Details:
The affected versions make unsafe memory accesses under the assumption that `#[repr(packed)]` has a guaranteed field order. 

The Rust specification does not guarantee this, and https://github.com/rust-lang/rust/pull/125360 (1.80.0-beta) starts 
reordering fields of `#[repr(packed)]` structs, leading to illegal memory accesses.

The patched versions `0.9.7` and `0.10.3` use `#[repr(C, packed)]`, which guarantees field order.
GitHub Security Advisory: GHSA-mjw4-jj88-v687
Package: phonenumber (RUST)
Severity: CRITICAL (CVSS 8.6)
CWE: CWE-248: Uncaught Exception, CWE-392: Missing Report of Error Condition, CWE-1284: Improper Validation of Specified Quantity in Input
Vulnerable versions: >= 0.3.4, < 0.3.6
Patched in: 0.3.6

Summary: panic on parsing crafted phonenumber inputs

Details:
### Impact
The phonenumber parsing code may panic due to a reachable `assert!` guard on the phonenumber string.

In a typical deployment of rust-phonenumber, this may get triggered by feeding a maliciously crafted phonenumber, e.g. over the network, specifically strings of the form `+dwPAA;phone-context=AA`, where the "number" part potentially parses as a number larger than 2^56.

Since f69abee1/0.3.4/#52.

0.2.x series is not affected.

### Patches
Upgrade to 0.3.6 or higher.

### Workarounds
n/a

### References
Whereas https://github.com/whisperfish/rust-phonenumber/issues/69 did not provide an example code path, property testing found a few: `+dwPAA;phone-context=AA`.
GitHub Security Advisory: GHSA-74r5-g7vc-j2v2
Package: zerovec-derive (RUST)
Severity: MODERATE (CVSS 6.2)
CWE: CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Vulnerable versions: < 0.9.7
Patched in: 0.9.7

Summary: zerovec-derive incorrectly uses `#[repr(packed)]`

Details:
The affected versions make unsafe memory accesses under the assumption that `#[repr(packed)]` has a guaranteed field order. 

The Rust specification does not guarantee this, and https://github.com/rust-lang/rust/pull/125360 (1.80.0-beta) starts 
reordering fields of `#[repr(packed)]` structs, leading to illegal memory accesses.

The patched versions `0.9.7` and `0.10.3` use `#[repr(C, packed)]`, which guarantees field order.
GitHub Security Advisory: GHSA-xrv3-jmcp-374j
Package: zerovec (RUST)
Severity: MODERATE (CVSS 6.2)
CWE: CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Vulnerable versions: < 0.9.7
Patched in: 0.9.7

Summary: zerovec incorrectly uses `#[repr(packed)]`

Details:
The affected versions make unsafe memory accesses under the assumption that `#[repr(packed)]` has a guaranteed field order. 

The Rust specification does not guarantee this, and https://github.com/rust-lang/rust/pull/125360 (1.80.0-beta) starts 
reordering fields of `#[repr(packed)]` structs, leading to illegal memory accesses.

The patched versions `0.9.7` and `0.10.4` use `#[repr(C, packed)]`, which guarantees field order.
GitHub Security Advisory: GHSA-xrv3-jmcp-374j
Package: zerovec (RUST)
Severity: MODERATE (CVSS 6.2)
CWE: CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Vulnerable versions: >= 0.10.0, < 0.10.4
Patched in: 0.10.4

Summary: zerovec incorrectly uses `#[repr(packed)]`

Details:
The affected versions make unsafe memory accesses under the assumption that `#[repr(packed)]` has a guaranteed field order. 

The Rust specification does not guarantee this, and https://github.com/rust-lang/rust/pull/125360 (1.80.0-beta) starts 
reordering fields of `#[repr(packed)]` structs, leading to illegal memory accesses.

The patched versions `0.9.7` and `0.10.4` use `#[repr(C, packed)]`, which guarantees field order.
GitHub Security Advisory: GHSA-2xpx-vcmq-5f72
Package: ntpd (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 0.3.1, <= 1.1.2
Patched in: 1.1.3

Summary: Unlimited number of NTS-KE connections can crash ntpd-rs server

Details:
### Summary
Missing limit for accepted NTS-KE connections allows an unauthenticated remote attacker to crash ntpd-rs when an NTS-KE server is configured. Non NTS-KE server configurations, such as the default ntpd-rs configuration, are unaffected.

### Details
Operating systems have a limit for the number of open file descriptors (which includes sockets) in a single process, e.g. 1024 on Linux by default. When ntpd-rs is configured as an NTS server, it accepts TCP connections for the NTS-KE service. If the process has reached the descriptor limit and tries to accept a new TCP connection, the accept() system call will return with the EMFILE error and cause ntpd-rs to abort.

A remote attacker can open a large number of parallel TCP connections to the server to trigger this crash. The connections need to be opened quickly enough to avoid the `key-exchange-timeout-ms` timeout (by default 1000 milliseconds).

### Impact
Only NTS-KE server configuration are affected. Those without an NTS-KE server configuration such as NTS client only or NTP only configuration are unaffected. For affected configurations the ntpd-rs daemon can made completely unavailable by crashing the service. If ntpd-rs is automatically restarted, an attacker can repeat the attack to prevent ntpd-rs from doing anything useful.

### Workarounds
- Disable NTS-KE server functionality
- Increase system resource limits (`RLIMIT_NOFILE`) to make the attack more difficult
- Lower the `key-exchange-timeout-ms` configuration setting to make the attack more difficult
GitHub Security Advisory: GHSA-9344-p847-qm5c
Package: sequoia-openpgp (RUST)
Severity: LOW (CVSS 2.9)
CWE: CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
Vulnerable versions: >= 1.13.0, < 1.21.0
Patched in: 1.21.0

Summary: Low severity (DoS) vulnerability in sequoia-openpgp

Details:
There is a denial-of-service vulnerability in sequoia-openpgp, our crate providing a low-level interface to our OpenPGP implementation. When triggered, the process will enter an infinite loop.

Many thanks to Andrew Gallagher for disclosing the issue to us.

## Impact

Any software directly or indirectly using the interface `sequoia_openpgp::cert::raw::RawCertParser`.  Notably, this includes all
software using the `sequoia_cert_store` crate.

## Details

The `RawCertParser` does not advance the input stream when encountering unsupported cert (primary key) versions, resulting in an infinite loop.

The fix introduces a new raw-cert-specific `cert::raw::Error::UnuspportedCert`.

## Affected software

- sequoia-openpgp 1.13.0
- sequoia-openpgp 1.14.0
- sequoia-openpgp 1.15.0
- sequoia-openpgp 1.16.0
- sequoia-openpgp 1.17.0
- sequoia-openpgp 1.18.0
- sequoia-openpgp 1.19.0
- sequoia-openpgp 1.20.0
- Any software built against a vulnerable version of sequoia-openpgp which is directly or indirectly using the interface sequoia_`openpgp::cert::raw::RawCertParser`.  Notably, this includes all software using the `sequoia_cert_store` crate.
GitHub Security Advisory: GHSA-x4gp-pqpj-f43q
Package: curve25519-dalek (RUST)
Severity: LOW (CVSS 2.9)
CWE: CWE-203: Observable Discrepancy
Vulnerable versions: < 4.1.3
Patched in: 4.1.3

Summary: curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`

Details:
Timing variability of any kind is problematic when working with  potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in `curve25519-dalek`.

The `Scalar29::sub` (32-bit) and `Scalar52::sub` (64-bit) functions contained usage of a mask value inside a loop where LLVM saw an opportunity to insert a branch instruction (`jns` on x86) to conditionally bypass this code section when the mask value is set to zero as can be seen in godbolt:

- 32-bit (see L106): https://godbolt.org/z/zvaWxzvqv
- 64-bit (see L48): https://godbolt.org/z/PczYj7Pda

A similar problem was recently discovered in the Kyber reference implementation:

https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ

As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away.

The fix can be validated in godbolt here:

- 32-bit: https://godbolt.org/z/jc9j7eb8E
- 64-bit: https://godbolt.org/z/x8d46Yfah

The problem was discovered and the solution independently verified by Alexander Wagner <alexander.wagner@aisec.fraunhofer.de> and Lea Themint <lea.thiemt@tum.de> using their DATA tool:

https://github.com/Fraunhofer-AISEC/DATA