CVE-2024-24564

Executive Summary

CVE-2024-24564 is a low-severity vulnerability in the Vyper smart contract language, affecting versions prior to 0.4.0. The flaw resides in the built-in extract32(b, start) function, which can read and return dirty memory if the start index parameter has a side effect that updates the byte array b. This could lead to unintended data exposure from the Ethereum Virtual Machine (EVM) memory, potentially leaking sensitive information stored in adjacent memory slots. The vulnerability is fixed in Vyper 0.4.0.

Supply Chain & Package Security

Vyper is a Python-based smart contract language for the Ethereum Virtual Machine (EVM). It is distributed via GitHub and the Python Package Index (PyPI). Developers using Vyper to write and deploy smart contracts should ensure they are using version 0.4.0 or later. The vulnerability does not affect the supply chain of Vyper itself but impacts the security of smart contracts compiled with vulnerable versions.

CVSS Breakdown & Threat Level

• CVSS Score: 3.7 (Low)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: None
• User Interaction: None
• Scope: Unchanged
• Confidentiality Impact: Low
• Integrity Impact: None
• Availability Impact: None

The low CVSS score reflects the limited impact: only confidentiality is affected, and the attacker must be able to trigger the vulnerable function with a crafted start index that causes a side effect. The vulnerability is not remotely exploitable in the traditional sense but can be triggered by a malicious smart contract or transaction.

Deep Dive & Mechanics

The extract32(b, start) function in Vyper is designed to extract 32 bytes from a byte array b starting at index start. The vulnerability arises when the start parameter is a complex expression that has a side effect of modifying b (e.g., by calling a function that updates the array). In such cases, the internal implementation may read from the original memory location of b after b has been updated, leading to reading uninitialized or dirty memory.

In the EVM, memory is a linear byte array that can be read and written. When a smart contract allocates memory, it may reuse previously freed memory slots that still contain stale data. If extract32 reads from such a slot, it could return data that was not intended to be exposed, potentially including private variables or other sensitive information.

The fix in Vyper 0.4.0 ensures that the extract32 function evaluates the start index and reads from b in a safe order, preventing the side effect from causing a read of dirty memory.

Vulnerable vs. Patched Code

Vulnerable Code (Vyper < 0.4.0):

@external
def vulnerable_extract(b: Bytes[64], start: uint256) -> Bytes[32]:
    # If start has a side effect that modifies b, dirty memory may be read
    return extract32(b, start)

Patched Code (Vyper 0.4.0):

@external
def patched_extract(b: Bytes[64], start: uint256) -> Bytes[32]:
    # The fix ensures safe evaluation order
    return extract32(b, start)

The patch is internal to the Vyper compiler; the user-facing syntax remains the same. The compiler now generates EVM bytecode that evaluates start and reads b in a way that prevents reading dirty memory.

Exploitation & Lab Setup

Red Team

To exploit this vulnerability, an attacker would need to craft a smart contract that calls extract32 with a start parameter that has a side effect of modifying the byte array b. For example:

@external
def exploit() -> Bytes[32]:
    b: Bytes[64] = b'\x01\x02...'  # some data
    # start is a function call that modifies b
    return extract32(b, self.modify_and_return(b))

@internal
def modify_and_return(b: Bytes[64]) -> uint256:
    # This function modifies b and returns a start index
    b = b'\xff\xff...'  # modify b
    return 0

If the vulnerable compiler processes this, extract32 may read from the original memory location of b after it has been modified, potentially returning dirty memory.

Blue Team

To detect exploitation attempts, monitor for smart contract transactions that call extract32 with complex start parameters that could have side effects. Static analysis of Vyper source code can identify such patterns. Additionally, runtime monitoring of EVM memory reads can detect reads from uninitialized memory.

Indicators of Compromise (IOCs)

• Smart Contract Bytecode: Contracts compiled with Vyper versions < 0.4.0 that use extract32 with a non-constant start parameter.
• Transaction Patterns: Transactions that call extract32 with a start parameter that is a function call or other expression with side effects.
• Memory Leakage: Unexpected data in return values of extract32 that does not match the expected byte array content.

Detection Engineering

YARA Rule

rule CVE_2024_24564_Vyper_Extract32 {
    meta:
        description = "Detects Vyper smart contracts compiled with vulnerable extract32 usage"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-24564"
    strings:
        $extract32 = "extract32" nocase
        $side_effect = /extract32\s*\([^)]*self\./ nocase
    condition:
        $extract32 and $side_effect
}

Sigma Rule

title: CVE-2024-24564 Vyper extract32 Dirty Memory Read
id: 8a4b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects potential exploitation of CVE-2024-24564 in Vyper smart contracts
author: Valters IT
date: 2024-01-01
logsource:
    category: blockchain
    product: ethereum
detection:
    selection:
        function: "extract32"
        start_param|contains: "self."
    condition: selection
falsepositives:
    - Legitimate use of self. in start parameter
level: low

Suricata Rule

alert ip any any -> any any (msg:"CVE-2024-24564 Vyper extract32 Dirty Memory Read"; content:"extract32"; content:"self."; distance:0; within:100; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

1. Upgrade Vyper: Update to Vyper version 0.4.0 or later. This is the only complete fix.
2. Code Review: Review all smart contracts using extract32 to ensure the start parameter is a constant or does not have side effects.
3. Static Analysis: Use static analysis tools to detect vulnerable patterns in Vyper source code.
4. Runtime Monitoring: Monitor smart contract execution for reads from uninitialized memory.
5. Input Validation: If possible, validate that the start parameter is a simple integer and not a function call.

Valters IT
DevSecOps & Cyber Threat Intelligence