[Security] #2023
Description
Affected area
API / request validation
Severity
Low
Impact
CRITICAL / RED-TEAM BOUNTY] Missing or incomplete producer signature verification in P2P block sync (consensus vulnerability)
Description
During P2P block synchronization (initial sync, catch-up after offline, or gossip propagation), nodes receive blocks from untrusted peers.
The current implementation appears to lack (or has incomplete) verification of the block producer's Ed25519 signature before accepting and applying the block to local state or forwarding it.
This is a critical consensus flaw: a malicious peer could feed forged/invalid blocks that pass basic structural checks but were not produced by a legitimate staked/miner with the correct private key.
Impact
- Temporary or permanent chain forks
- Invalid block acceptance leading to divergent state
- Potential for eclipse attacks or reorg exploitation during sync
- Breaks the "1 CPU = 1 Vote" / Proof-of-Antiquity integrity if bad blocks propagate
Similar issues (e.g., /relay/ping signature verification) have been bountied and paid out quickly (see #388 for precedent).
Suggested Fix
Add explicit producer signature verification in the P2P sync/block validation path, before apply_block() or equivalent:
// Example in sync handler (p2p/sync.rs or consensus/validation.rs)
fn validate_incoming_block(block: &Block, peer_id: &PeerId) -> Result<(), ConsensusError> {
let block_hash = block.compute_hash(); // or header hash
// Lookup producer pubkey (from header, registry, or stake list)
let producer_pubkey = get_producer_pubkey(&block.producer_id)?;
if !ed25519_verify(&producer_pubkey, &block_hash, &block.producer_signature) {
penalize_or_ban_peer(peer_id, BanReason::InvalidSignature);
return Err(ConsensusError::InvalidProducerSignature);
}
// Then proceed with full validation + apply
apply_block(block)
}
### Reproduction steps
Steps to Reproduce
1. Run a node or use the P2P interface.
2. Simulate a peer sending a block with invalid/missing producer signature.
3. Observe whether it’s accepted into the chain state without rejection.
Wallet RTC2b168281407a7cddc0133786£94b5793210
9565a
### Affected versions / environments
Impact
Temporary or permanent chain forks
Invalid block acceptance leading to divergent state
Potential for eclipse attacks or reorg exploitation during sync
Breaks the "1 CPU = 1 Vote" / Proof-of-Antiquity integrity if bad blocks propagate
Similar issues (e.g., /relay/ping signature verification) have been bountied and paid out quickly (see https://github.com/Scottcjn/Rustchain/pull/388 for precedent).
### Suggested mitigation
Suggested Fix
Add explicit producer signature verification in the P2P sync/block validation path, before apply_block() or equivalent:
// Example in sync handler (p2p/sync.rs or consensus/validation.rs)
fn validate_incoming_block(block: &Block, peer_id: &PeerId) -> Result<(), ConsensusError> {
let block_hash = block.compute_hash(); // or header hash
// Lookup producer pubkey (from header, registry, or stake list)
let producer_pubkey = get_producer_pubkey(&block.producer_id)?;
if !ed25519_verify(&producer_pubkey, &block_hash, &block.producer_signature) {
penalize_or_ban_peer(peer_id, BanReason::InvalidSignature);
return Err(ConsensusError::InvalidProducerSignature);
}
// Then proceed with full validation + apply
apply_block(block)
}
### Checklist
- [x] I did not include secrets, private keys, or unpublished credentials.
- [x] This is not a bounty claim or wallet registration request.