Summary

The lib.rs file contains a critical vulnerability due to inadequate checks and synchronization in the transaction reversion process.

This vulnerability can be exploited to cause data corruption, unauthorized transactions, and denial of service (DoS) attacks. Proper validation and synchronization mechanisms are necessary to ensure the integrity and reliability of the system.

Vulnerable Code and file.

https://github.com/rooch-network/rooch/blob/main/crates/rooch-db/src/lib.rs

The vulnerability is primarily located in the revert_tx and do_revert_tx_ignore_check methods, where transaction and state changes are reverted without comprehensive checks and synchronization:

pub fn revert_tx(&self, tx_hash: H256) -> Result<()> {
let last_sequencer_info = self
.rooch_store
.get_meta_store()
.get_sequencer_info()?
.ok_or_else(|| anyhow::anyhow!("Load sequencer info failed"))?;

let ledger_tx_opt = self
    .rooch_store
    .transaction_store
    .get_transaction_by_hash(tx_hash)?;
if ledger_tx_opt.is_none() {
    println!("the ledger tx not exist via tx_hash {}", tx_hash);
    return Ok(());
}
let sequencer_info = ledger_tx_opt.unwrap().sequence_info;
let tx_order = sequencer_info.tx_order;
assert_eq!(
    sequencer_info.tx_order, last_sequencer_info.last_order,
    "the last order {} should match current sequencer info tx order {}, tx_hash {}",
    last_sequencer_info.last_order, sequencer_info.tx_order, tx_hash
);

self.do_revert_tx_ignore_check(tx_hash)?;
// Additional code omitted for brevity

}

pub fn do_revert_tx_ignore_check(&self, tx_hash: H256) -> Result<()> {
let ledger_tx_opt = self
.rooch_store
.transaction_store
.get_transaction_by_hash(tx_hash)?;

if ledger_tx_opt.is_none() {
    println!("the ledger tx not exist via tx_hash {}", tx_hash);
    return Ok(());
}

let sequencer_info = ledger_tx_opt.unwrap().sequence_info;
let tx_order = sequencer_info.tx_order;
self.rooch_store
    .transaction_store
    .remove_transaction(tx_hash, tx_order)?;
self.moveos_store
    .transaction_store
    .remove_tx_execution_info(tx_hash)?;
// Additional code omitted for brevity

}

Detailed Description.

Nature of the Vulnerability

The revert_tx and do_revert_tx_ignore_check functions handle the reversion of transactions and associated state changes.

The critical issues are:

Lack of Comprehensive Checks: The code assumes that the transaction and state change set exist and are valid for reversion. If these assumptions are incorrect, the reversion process might fail silently or partially, leading to inconsistent state.

No Synchronization: The methods access and modify shared state without synchronization mechanisms. In a concurrent environment, this can lead to race conditions, where multiple threads or tasks attempt to revert transactions simultaneously, causing data corruption or loss.

Impact.

Data Corruption: Inconsistent or partial reversion of transactions can corrupt the state, affecting the integrity of the blockchain or ledger.

Unauthorized State Changes: Lack of checks and synchronization might allow unauthorized or unintended state changes, potentially leading to security breaches.

Denial of Service (DoS): If the system state becomes corrupted, it might lead to service downtime or failure, impacting users and operations.

Financial Loss: Unauthorized actions and data corruption can result in direct financial losses and damage to the organization's reputation.

Severity.

The severity of this issue is critical.

due to the potential for data corruption, unauthorized state changes, and denial of service, all of which can have significant operational and security
impacts.

Attack Scenario.

Identify the Reversion Process:

An attacker identifies that the revert_tx and do_revert_tx_ignore_check functions handle transaction reversion without comprehensive checks and synchronization.

Craft Malicious Transactions:

The attacker submits transactions that are designed to be reverted. These transactions might be crafted to manipulate the state in a way that benefits the attacker when reverted.

Trigger Concurrent Reversions:

By exploiting the lack of synchronization, the attacker triggers multiple reversion processes concurrently. This can be done by submitting multiple revert requests in rapid succession.

Cause Inconsistent State:

The concurrent reversion processes, without proper synchronization, can lead to inconsistent or partial state changes. This inconsistency can corrupt the ledger or blockchain state.

Exploit Data Corruption:

With the state corrupted, the attacker might exploit the inconsistencies to perform unauthorized actions. For example, they might manipulate balances or transaction histories to their advantage.

Bypass Security Checks:

The lack of comprehensive checks means that the attacker can bypass certain security measures during the reversion process, allowing them to revert transactions that should not be reverted.

Proof of Concept (PoC).

To demonstrate the issue, consider the following scenario:

Setup: Ensure the application is running with the lib.rs module integrated.

Concurrent Transaction Reversion:

Simulate concurrent transaction reversion requests by triggering the revert_tx function from multiple threads or processes simultaneously.

Observe Inconsistent State:

Monitor the state of the ledger or blockchain for inconsistencies or unexpected behavior during concurrent execution.

Example Code to Trigger the Vulnerability

use std::sync::Arc;
use std::thread;
use std::time::Duration;

fn main() {
// Assume RoochDB::new is properly defined to initialize a RoochDB instance
let rooch_db = Arc::new(RoochDB::init(/* parameters omitted */).unwrap());

// Simulate concurrent transaction reversion
let handles: Vec<_> = (0..10).map(|_| {
    let rooch_db = Arc::clone(&rooch_db);
    thread::spawn(move || {
        let tx_hash = /* generate or retrieve a transaction hash */;
        rooch_db.revert_tx(tx_hash).unwrap();
    })
}).collect();

// Wait for all threads to complete
for handle in handles {
    handle.join().unwrap();
}

// Check for inconsistencies in the state
// This could involve checking logs, state variables, or transaction outcomes

}

Recommendations.

To mitigate this issue, implement the following:

Comprehensive Checks: Ensure that all necessary checks are in place before proceeding with transaction reversion. Validate the existence and integrity of transactions and state change sets.

Synchronization Mechanisms: Use synchronization primitives (e.g., Mutex, RwLock) to protect shared state and prevent race conditions during transaction reversion.