nimiq-blockchain

Impact

The validity store treats a transaction with stored block_number = X as "in window" only when X > last_bn - transaction_validity_window_blocks (strict inequality). However the protocol's Transaction::is_valid_at accepts a transaction for inclusion in any block in [validity_start_height - blocks_per_batch, validity_start_height + window - 1]. By choosing validity_start_height = X + blocks_per_batch (the largest value still compatible with first inclusion at block X), an attacker can replay the same signed transaction in any block B such that X + window < B < validity_start_height + window, i.e., a contiguous window of blocks_per_batch - 1 blocks (59 on MainNet, ~10 minutes) during which the replay-protection check fails to flag it. The same transaction is then executed twice: the sender is debited twice, the recipient credited twice.

Patches

https://github.com/nimiq/core-rs-albatross/pull/3772

Workarounds

No known workarounds

Impact

A remote peer can crash any full node by sending a RequestBatchSet message containing the genesis block's hash. The handler calls get_epoch_chunks which iterates backwards through macro blocks using Policy::macro_block_before. When it reaches the genesis block number, macro_block_before panics with "No macro blocks before genesis block".

Patches

The patch for this vulnerability is formally released as part of v1.5.0.

Workarounds

No Workaround, although requesting the genesis batch set is not used during normal operation.

Resources

See PR.

Impact

HistoryStore::put_historic_txns uses an assert! to enforce invariants about HistoricTransaction.block_number (must be within the macro block being pushed and within the same epoch). During history sync, a peer can influence the history: &[HistoricTransaction] input passed into Blockchain::push_history_sync, and a malformed history list can violate these invariants and trigger a panic.

extend_history_sync calls this.history_store.add_to_history(..) before comparing the computed history root against the macro block header (block.history_root()), so the panic can happen before later rejection checks run.

Patches

The patch for this vulnerability is included as part of v1.3.0.

Workarounds

No known workarounds.

Impact

Block timestamp validation enforces that timestamp >= parent.timestamp for non-skip blocks and timestamp == parent.timestamp + MIN_PRODUCER_TIMEOUT for skip blocks, but there is no visible upper bound check against the wall clock. A malicious block-producing validator can set block timestamps arbitrarily far in the future. This directly affects reward calculations via Policy::supply_at() and batch_delay() in blockchain/src/reward.rs, inflating the monetary supply beyond the intended emission schedule.

Patches

TBD

Workarounds

No know workarounds.

Impact

The validity store treats a transaction with stored block_number = X as "in window" only when X > last_bn - transaction_validity_window_blocks (strict inequality). However the protocol's Transaction::is_valid_at accepts a transaction for inclusion in any block in [validity_start_height - blocks_per_batch, validity_start_height + window - 1]. By choosing validity_start_height = X + blocks_per_batch (the largest value still compatible with first inclusion at block X), an attacker can replay the same signed transaction in any block B such that X + window < B < validity_start_height + window, i.e., a contiguous window of blocks_per_batch - 1 blocks (59 on MainNet, ~10 minutes) during which the replay-protection check fails to flag it. The same transaction is then executed twice: the sender is debited twice, the recipient credited twice.

Patches

https://github.com/nimiq/core-rs-albatross/pull/3772

Workarounds

No known workarounds

Impact

A remote peer can crash any full node by sending a RequestBatchSet message containing the genesis block's hash. The handler calls get_epoch_chunks which iterates backwards through macro blocks using Policy::macro_block_before. When it reaches the genesis block number, macro_block_before panics with "No macro blocks before genesis block".

Patches

The patch for this vulnerability is formally released as part of v1.5.0.

Workarounds

No Workaround, although requesting the genesis batch set is not used during normal operation.

Resources

See PR.

Impact

HistoryStore::put_historic_txns uses an assert! to enforce invariants about HistoricTransaction.block_number (must be within the macro block being pushed and within the same epoch). During history sync, a peer can influence the history: &[HistoricTransaction] input passed into Blockchain::push_history_sync, and a malformed history list can violate these invariants and trigger a panic.

extend_history_sync calls this.history_store.add_to_history(..) before comparing the computed history root against the macro block header (block.history_root()), so the panic can happen before later rejection checks run.

Patches

The patch for this vulnerability is included as part of v1.3.0.

Workarounds

No known workarounds.

Impact

Block timestamp validation enforces that timestamp >= parent.timestamp for non-skip blocks and timestamp == parent.timestamp + MIN_PRODUCER_TIMEOUT for skip blocks, but there is no visible upper bound check against the wall clock. A malicious block-producing validator can set block timestamps arbitrarily far in the future. This directly affects reward calculations via Policy::supply_at() and batch_delay() in blockchain/src/reward.rs, inflating the monetary supply beyond the intended emission schedule.

Patches

TBD

Workarounds

No know workarounds.

Impact

The validity store treats a transaction with stored block_number = X as "in window" only when X > last_bn - transaction_validity_window_blocks (strict inequality). However the protocol's Transaction::is_valid_at accepts a transaction for inclusion in any block in [validity_start_height - blocks_per_batch, validity_start_height + window - 1]. By choosing validity_start_height = X + blocks_per_batch (the largest value still compatible with first inclusion at block X), an attacker can replay the same signed transaction in any block B such that X + window < B < validity_start_height + window, i.e., a contiguous window of blocks_per_batch - 1 blocks (59 on MainNet, ~10 minutes) during which the replay-protection check fails to flag it. The same transaction is then executed twice: the sender is debited twice, the recipient credited twice.

Patches

https://github.com/nimiq/core-rs-albatross/pull/3772

Workarounds

No known workarounds

Impact

A remote peer can crash any full node by sending a RequestBatchSet message containing the genesis block's hash. The handler calls get_epoch_chunks which iterates backwards through macro blocks using Policy::macro_block_before. When it reaches the genesis block number, macro_block_before panics with "No macro blocks before genesis block".

Patches

The patch for this vulnerability is formally released as part of v1.5.0.

Workarounds

No Workaround, although requesting the genesis batch set is not used during normal operation.

Resources

See PR.

Impact

HistoryStore::put_historic_txns uses an assert! to enforce invariants about HistoricTransaction.block_number (must be within the macro block being pushed and within the same epoch). During history sync, a peer can influence the history: &[HistoricTransaction] input passed into Blockchain::push_history_sync, and a malformed history list can violate these invariants and trigger a panic.

extend_history_sync calls this.history_store.add_to_history(..) before comparing the computed history root against the macro block header (block.history_root()), so the panic can happen before later rejection checks run.

Patches

The patch for this vulnerability is included as part of v1.3.0.

Workarounds

No known workarounds.

Impact

Block timestamp validation enforces that timestamp >= parent.timestamp for non-skip blocks and timestamp == parent.timestamp + MIN_PRODUCER_TIMEOUT for skip blocks, but there is no visible upper bound check against the wall clock. A malicious block-producing validator can set block timestamps arbitrarily far in the future. This directly affects reward calculations via Policy::supply_at() and batch_delay() in blockchain/src/reward.rs, inflating the monetary supply beyond the intended emission schedule.

Patches

TBD

Workarounds

No know workarounds.