Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SECURITY] Non-Compliance in Memory Allocation for KECCAK256 #1246

Open
mhoste51 opened this issue Nov 22, 2024 · 1 comment · May be fixed by #1253
Open

[SECURITY] Non-Compliance in Memory Allocation for KECCAK256 #1246

mhoste51 opened this issue Nov 22, 2024 · 1 comment · May be fixed by #1253
Assignees

Comments

@mhoste51
Copy link

Our team at FuzzingLabs identified a non-compliance issue in the KECCAK256 implementation. During the execution of the this opcode, LEVM incorrectly allocates memory even when the size parameter is zero. This behavior deviates from expected EVM standards as implemented in widely adopted EVMs like REVM and Geth. Allocating memory in this scenario is unnecessary and results in an inflated memory size (MSIZE) and unnecessary gas consumption.

Root cause

    pub fn op_keccak256(
        &mut self,
        current_call_frame: &mut CallFrame,
    ) -> Result<OpcodeSuccess, VMError> {
        let offset: usize = current_call_frame
            .stack
            .pop()?
            .try_into()
            .map_err(|_| VMError::VeryLargeNumber)?;
        let size: usize = current_call_frame
            .stack
            .pop()?
            .try_into()
            .map_err(|_| VMError::VeryLargeNumber)?;

        let gas_cost =
            gas_cost::keccak256(current_call_frame, size, offset).map_err(VMError::OutOfGas)?;

        self.increase_consumed_gas(current_call_frame, gas_cost)?;

        let value_bytes = current_call_frame.memory.load_range(offset, size)?;

        let mut hasher = Keccak256::new();
        hasher.update(value_bytes);
        let result = hasher.finalize();
        current_call_frame
            .stack
            .push(U256::from_big_endian(&result))?;

        Ok(OpcodeSuccess::Continue)
    }
let value_bytes = current_call_frame.memory.load_range(offset, size)?;
  • Even when size == 0, the memory is unnecessarily extended up to the offset.
  • This leads to unnecessary memory allocation.

For example:

  • Input: offset = 1, size = 0.
  • Expected memory after KECCAK256: No changes, MSIZE should return 0.
  • Actual memory after KECCAK256: Memory is extended to 32 bytes, and MSIZE incorrectly returns 32.

Recommendations

To align LEVM with expected EVM behavior:

  1. Modify the op_keccak256 implementation to check if size = 0 before performing memory allocation.
  2. Ensure that memory operations are skipped entirely when size = 0, and return the Keccak256 hash of an empty byte array.

Step to reproduce

Payload

[88, 88, 32, 89]
PC
PC
KECCAK256
MSIZE

Add to test :

#[test]
fn test_non_compliance_keccak256() {
    let mut vm = new_vm_with_bytecode(Bytes::copy_from_slice(&[88, 88, 32, 89]))
    .unwrap();
    let mut current_call_frame = vm.call_frames.pop().unwrap();
    vm.execute(&mut current_call_frame);
    assert_eq!(current_call_frame.stack.stack[0], U256::from_str("0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470").unwrap());
    assert_eq!(current_call_frame.stack.stack[1], U256::zero());
}

Backtrace

thread 'test_non_compliance_keccak256' panicked at crates/vm/levm/tests/edge_case_tests.rs:14:5:
assertion `left == right` failed
  left: 32
 right: 0
stack backtrace:
   0: rust_begin_unwind
             at /rustc/8adb4b30f40e6fbd21dc1ba26c3301c7eeb6de3c/library/std/src/panicking.rs:665:5
   1: core::panicking::panic_fmt
             at /rustc/8adb4b30f40e6fbd21dc1ba26c3301c7eeb6de3c/library/core/src/panicking.rs:76:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
             at /home/mhoste/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/panicking.rs:373:5
   4: edge_case_tests::test_non_compliance_keccak256
             at ./tests/edge_case_tests.rs:14:5
   5: edge_case_tests::test_non_compliance_keccak256::{{closure}}
             at ./tests/edge_case_tests.rs:9:35
   6: core::ops::function::FnOnce::call_once
             at /home/mhoste/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5
   7: core::ops::function::FnOnce::call_once
             at /rustc/8adb4b30f40e6fbd21dc1ba26c3301c7eeb6de3c/library/core/src/ops/function.rs:250:5
@shreyas-londhe
Copy link

Hi, can I pick up this issue?

@ilitteri ilitteri self-assigned this Nov 25, 2024
@ilitteri ilitteri linked a pull request Nov 25, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

Successfully merging a pull request may close this issue.

3 participants