Threats Tagged 'crates-io'

### Impact LDAP queries are not validated for depth, which can cause the parser (both PEG and ASN) to exhaust the stack. This *may* cause a denial of service in applications that process queries. ### Workarounds N/A ### References Related to GHSA-r5fr-9gmv-jggh

A `SELECT` permission defined on an array element (`DEFINE FIELD field.* … PERMISSIONS FOR select …`) is not enforced correctly for `RECORD` users. Instead of hiding the denied elements, the query leaks a subset of them: a deny-all returns the odd-indexed elements, and a per-element predicate keeps and drops the wrong ones. The filter removed each denied element by index while walking the array forwards. Because removing an element shifts every later index down, each cut invalidated the indices still pending in the loop, leaving denied elements behind. Field-level permissions are enforced correctly; only the element (`field.*`) level is affected, and only for record users — root and record-owner sessions are not. ## Impact What an attacker **can** do: - As a record (scope) user, read array elements that an element-level (`field.*`) SELECT permission should hide, on any table they can already SELECT. - Recover denied elements through both a deny-all and a `WHERE` predicate — the wrong elements are selected either way. What it **can't** do: - Bypass field-level SELECT permissions, which are evaluated correctly. - Affect root or record-owner sessions, or cross namespace/database isolation. - Modify data, escalate privileges, or affect availability (confidentiality only). ## Patches The three permission-filtering paths (`doc/reduce.rs`, `doc/output.rs`, `exec/operators/scan/pipeline.rs`) now remove denied elements in reverse index order, so removing one element no longer shifts the elements still to be checked. Regression tests reproducing the issue were added. The fix is included in SurrealDB 3.1.4. ## Workarounds - Do not rely on element-level (`field.*`) permissions to hide data from record users; use field-level permissions, which are enforced correctly. - Restrict record users from selecting tables whose schema uses element-level permissions. ## Resources - [DEFINE FIELD](https://surrealdb.com/docs/surrealql/statements/define/field) - [USERS](https://surrealdb.com/docs/learn/security/authentication/authentication) - [DEFINE TABLE … PERMISSIONS](https://surrealdb.com/docs/surrealql/statements/define/table) - `fix(sec): stop array element-level SELECT permissions leaking elements` (commit `8f89b260b`)

Nimiq is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Through 1.5.0, the validity store uses a strict lower-bound comparison that expires a stored transaction too early relative to Transaction::is_valid_at, allowing a remote attacker to replay the same signed transaction during a blocks_per_batch minus one block window and cause the sender and recipient balances to be updated twice. This issue is fixed in version 1.5.1.

Russh is a Rust SSH client & server library. Prior to 0.62.5, russh dispatches channel-scoped Handler callbacks for recipient channel IDs that were never opened or confirmed in russh/src/server/encrypted.rs, server_read_authenticated, and the exec_request callback. Version 0.62.5 fixes the issue.

### Summary `NonFinalizedState::handle_reorg` is a recursive, unbounded async function that traverses parent blocks until it finds a common ancestor on the main chain. It has **no recursion depth limit** and **no cycle detection**. A malicious or buggy validator can serve a block whose `previous_block_hash` points back to itself (or forms a cycle with other blocks), causing `handle_reorg` to infinite-loop, consuming 100% CPU and never making sync progress. Additionally, `update()` contains an `.expect("empty snapshot impossible")` that panics if the non-finalized snapshot becomes empty after trimming finalized blocks. ### Details **Location:** `packages/zaino-state/src/chain_index/non_finalised_state.rs:443-489` ```rust async fn handle_reorg( &self, working_snapshot: &mut NonfinalizedBlockCacheSnapshot, block: &impl Block, ) -> Result<IndexedBlock, SyncError> { let prev_block = match working_snapshot .get_block_by_hash_bytes_in_serialized_order(block.prev_hash_bytes_serialized_order()) .cloned() { Some(prev_block) => { if !working_snapshot .heights_to_hashes .values() .any(|hash| hash == prev_block.hash()) { Box::pin(self.handle_reorg(working_snapshot, &prev_block)).await? // <-- LINE 459 } else { prev_block } } None => { let prev_block = self .source .get_block(HashOrHeight::Hash( zebra_chain::block::Hash::from_bytes_in_serialized_order( block.prev_hash_bytes_serialized_order(), ), )) .await .map_err(|e| { ... })? .ok_or(SyncError::ValidatorConnectionError(...))?; Box::pin(self.handle_reorg(working_snapshot, &*prev_block)).await? // <-- LINE 483 } }; let indexed_block = block.to_indexed_block(&prev_block, self).await?; working_snapshot.add_block_new_chaintip(indexed_block.clone()); Ok(indexed_block) } ``` **Infinite loop via self-referencing block:** 1. A compromised validator serves a block `B` where `B.prev_hash == B.hash`. 2. `handle_reorg` is called with `B`. 3. `get_block_by_hash_bytes_in_serialized_order(B.prev_hash)` finds `B` itself in `working_snapshot.blocks`. 4. Check: is `B.hash` in `working_snapshot.heights_to_hashes`? If `B` is a new chaintip not yet on the main chain, **no**. 5. Recurse with `prev_block` = `B` (the exact same block). 6. This repeats forever. The async recursion builds a new `Box::pin` future each iteration, consuming heap memory and CPU. **Stack exhaustion via deep reorg:** A deep reorg of >1000 blocks would recurse >1000 times. Each async recursion creates a new `Box::pin` future on the heap. While this won't exhaust the native stack immediately, it will allocate unbounded heap memory and CPU time, effectively DoS-ing the sync task. **`.expect("empty snapshot impossible")` panic:** **Location:** `packages/zaino-state/src/chain_index/non_finalised_state.rs:543-548` ```rust new_snapshot.remove_finalized_blocks(finalized_height); let best_block = &new_snapshot .blocks .values() .max_by_key(|block| block.chainwork()) .cloned() .expect("empty snapshot impossible"); // <-- LINE 548 ``` If `finalized_height` is greater than or equal to all blocks in `new_snapshot.blocks`, `remove_finalized_blocks` retains only blocks at or above that height. If none exist, `new_snapshot.blocks` becomes empty. The `.expect()` then panics. While the comment claims this is "impossible," defensive programming dictates it is reachable under corruption or edge-case sync conditions. ### PoC 1. Run a regtest. 2. Serve a block where `header.previous_block_hash == block.hash()`. 3. Zaino's `NonFinalizedState::sync` enters `handle_reorg` and infinite-loops. 4. Sync never completes. CPU usage pegs to 100%. No new blocks are served to clients. ### Fix 1. **Add an explicit recursion depth limit** (e.g., max 1000 iterations) and return `SyncError::ReorgFailure` if exceeded: ```rust const MAX_REORG_DEPTH: usize = 1000; ``` 2. **Track visited hashes** in a `HashSet<BlockHash>` during traversal to detect cycles and abort with an error. 3. **Replace `.expect("empty snapshot impossible")`** with a proper `Err(UpdateError::DatabaseHole)` or similar error return. ### Additional Attack Vectors - **Deep reorg DoS:** A miner with significant hash power (or a compromised validator) triggers a deep reorg. Zaino spends excessive CPU and memory in `handle_reorg`, starving the async runtime and stalling response serving. - **Fork-choice manipulation:** By serving cyclic or very deep sidechains, an attacker can keep Zaino stuck in reorg handling indefinitely, preventing it from ever serving the real best chain.

### Impact `skilo add` installs a skill by recursively copying the skill directory into the target skills directory. The copy routine (`copy_dir_all`) classified each entry with `std::fs::DirEntry::file_type()` — which does **not** follow symlinks — and then copied non-directory entries with `std::fs::copy()`, which **does** dereference symlinks. As a result, a skill containing a symbolic link such as `reference.txt -> /home/<user>/.ssh/id_rsa` was copied as a regular file whose contents are the link's **target**. A malicious skill source — for example a git repository installed via `skilo add github.com/<attacker>/<skills>`, or a local path — could read arbitrary files readable by the user running `skilo add` (SSH keys, cloud credentials, `.env` files, etc.) and place their contents inside the installed skill directory, where the user or their agent may later read, share, or sync them. This is arbitrary local file disclosure (CWE-59 / CWE-61, symlink following) triggered by installing an untrusted skills source. ### Patches Fixed in **0.11.1**. `copy_dir_all` now rejects symbolic-link entries at any recursion depth (failing closed with a dedicated error) instead of dereferencing them. ### Workarounds - Only install skills from sources you trust. - Inspect a skill source for symbolic links before running `skilo add`. ### Affected versions Introduced together with the `skilo add` command in 0.5.0 and present through 0.11.0. Releases before 0.5.0 do not include the `add` command.