apegurus/logic-errors

<!-- Source: DeFiFoFum/fofum-solidity-skills (MIT) --> <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->

Logic Bug Exploits

Overview

Logic bugs are flaws in business logic that allow unintended behavior. Unlike pattern-based vulnerabilities (reentrancy, overflow), these require understanding the protocol's intended behavior to identify.

Key insight: Logic bugs are the hardest to find automatically and cause the largest losses.

---

Attack Patterns

1. Incorrect State Machine

// VULNERABLE: Can withdraw multiple times
enum Status { Pending, Approved, Withdrawn }
mapping(uint256 => Status) public requestStatus;

function withdraw(uint256 requestId) external {
    require(requestStatus[requestId] == Status.Approved, "Not approved");
    // Missing: requestStatus[requestId] = Status.Withdrawn;
    payable(msg.sender).transfer(amounts[requestId]);
}

2. Order of Operations

// VULNERABLE: Update after external call
function redeem(uint256 shares) external {
    uint256 assets = convertToAssets(shares);
    asset.transfer(msg.sender, assets);  // External call first
    _burn(msg.sender, shares);           // State update after
}

// SECURE: CEI pattern
function redeem(uint256 shares) external {
    uint256 assets = convertToAssets(shares);
    _burn(msg.sender, shares);           // State update first
    asset.transfer(msg.sender, assets);  // External call after
}

3. Accounting Errors

// VULNERABLE: Doesn't account for existing balance
function deposit() external payable {
    balances[msg.sender] = msg.value;  // Overwrites, doesn't add!
}

// SECURE
function deposit() external payable {
    balances[msg.sender] += msg.value;
}

4. Precision Loss

// VULNERABLE: Division before multiplication
function calculateReward(uint256 amount, uint256 rate) external pure returns (uint256) {
    return amount / 1000 * rate;  // Loses precision
}

// SECURE: Multiplication before division
function calculateReward(uint256 amount, uint256 rate) external pure returns (uint256) {
    return amount * rate / 1000;
}

5. Edge Case Handling

// VULNERABLE: Division by zero when totalSupply is 0
function pricePerShare() external view returns (uint256) {
    return totalAssets() / totalSupply();  // Reverts if no shares
}

// SECURE
function pricePerShare() external view returns (uint256) {
    uint256 supply = totalSupply();
    return supply == 0 ? 1e18 : totalAssets() * 1e18 / supply;
}

---

Real Exploits

Nomad Bridge (Aug 2022) — $190M

What happened:

• Routine upgrade initialized confirmAt mapping with zero
• Zero was a valid "confirmed" state
• Anyone could submit fake messages as "already proven"
• Mass exploitation by hundreds of addresses

Root cause: Invalid initialization treated as valid state

// The bug: messages[_messageHash] = 0 was treated as confirmed
function process(bytes memory _message) public returns (bool _success) {
    bytes32 _messageHash = keccak256(_message);
    require(acceptableRoot(messages[_messageHash]), "not accepted");
    // 0 passed acceptableRoot check!
}

Lesson: Be explicit about valid states. Zero should not be a valid confirmed state.

Compound (Sept 2021) — $80M+

What happened:

• Upgrade introduced bug in reward distribution
• comptroller.compAccrued() returned wrong values
• Users could claim excessive COMP rewards

Root cause: Incorrect accounting in upgrade

Lesson: Test upgrades extensively. State transitions are dangerous.

Level Finance (May 2023) — $1.1M

What happened:

• Referral reward calculation bug
• Could claim referral rewards multiple times
• Self-referral exploit

Root cause: Missing state update after reward claim

Saddle Finance (Apr 2022) — $10M

What happened:

• Virtual price calculation bug in meta-pool
• Attacker manipulated LP token value
• Withdrew more than deposited

Root cause: Incorrect share calculation with rounding

---

Detection Checklist

State Machine

• [ ] Are all state transitions explicitly handled?
• [ ] Can states be skipped or repeated?
• [ ] Is there a state that represents "completed" to prevent re-execution?
• [ ] Are default/zero values handled as invalid states?

Accounting

• [ ] Does deposit add to existing balance (not overwrite)?
• [ ] Does withdrawal subtract correctly?
• [ ] Are shares/assets conversions precise?
• [ ] Is totalSupply/totalAssets always consistent?

Math & Precision

• [ ] Is multiplication done before division?
• [ ] Are there division-by-zero possibilities?
• [ ] Is precision loss handled (rounding direction)?
• [ ] Are there overflow possibilities in intermediate calculations?

Edge Cases

• [ ] What happens with zero amounts?
• [ ] What happens with very small/large values?
• [ ] What happens on first deposit (empty pool)?
• [ ] What happens on last withdrawal (drain pool)?
• [ ] What happens with self-referral/self-liquidation?

Protocol-Specific

• [ ] Can rewards be claimed multiple times?
• [ ] Can positions be liquidated incorrectly?
• [ ] Are fees calculated and deducted correctly?
• [ ] Can users bypass intended restrictions?

Finding Logic Bugs

1. Understand Intended Behavior

• Read docs, comments, specs
• What SHOULD happen?
• What are the invariants?

2. Trace State Changes

• Follow every state variable modification
• Map out the state machine
• Find missing transitions

3. Test Boundaries

• Zero values
• Max values
• First/last operations
• Empty states

4. Question Assumptions

• "Users won't do X" — They will
• "This value can't be zero" — It can
• "This is called after Y" — Is it enforced?

5. Think Like an Attacker

• What's the most valuable exploit?
• What if I could control X?
• What if I did operations out of order?

---

Secure Patterns

Explicit State Machine

enum State { Created, Active, Completed, Cancelled }

modifier inState(State expected) {
    require(state == expected, "Invalid state");
    _;
}

function complete() external inState(State.Active) {
    state = State.Completed;  // Explicit transition
    // Do completion logic
}

Invariant Checks

function _checkInvariants() internal view {
    assert(totalAssets >= totalLiabilities);
    assert(totalShares == 0 || totalAssets > 0);
    // Add protocol-specific invariants
}

function deposit(uint256 assets) external {
    // ... deposit logic ...
    _checkInvariants();
}

CEI Pattern (Checks-Effects-Interactions)

function withdraw(uint256 amount) external {
    // CHECKS
    require(balances[msg.sender] >= amount, "Insufficient");
    
    // EFFECTS
    balances[msg.sender] -= amount;
    
    // INTERACTIONS
    payable(msg.sender).transfer(amount);
}

---

References

• Nomad Hack Analysis (samczsun)
• Compound Bug Post-Mortem
• Trail of Bits: Not So Smart Contracts

Validation Heuristics (kadenzipfel)

Preconditions

• Contract uses require() statements for input or state validation
• The require condition is overly restrictive (rejects valid inputs) or too loose (accepts invalid inputs)
• OR: require() validates return values from external contracts whose behavior doesn't match assumptions

Vulnerable Pattern

// Overly restrictive: blocks legitimate use case
function withdraw(uint256 amount) external {
    // Fails if user has exactly the required amount (should be >=)
    require(balances[msg.sender] > amount, "insufficient");
    balances[msg.sender] -= amount;
    payable(msg.sender).transfer(amount);
}

// External contract assumption mismatch
function processPayment(IERC20 token, uint256 amount) external {
    // Assumes transfer returns true, but some tokens don't return a value
    // require reverts on tokens like USDT
    require(token.transfer(msg.sender, amount), "failed");
}

// Missing error message
function setRate(uint256 rate) external {
    require(rate > 0); // No error message — difficult to debug
}

Detection Heuristics

1. For each require(), verify the condition matches the documented business logic (e.g., > vs >=, < vs <=)
2. Check if require() validates an external call's return value — verify the external contract actually returns what's expected
3. Look for require() without error messages — while not a vulnerability, it makes debugging difficult
4. Check if overly strict requirements can DoS critical paths (e.g., withdrawals, liquidations)
5. Check chained contract calls: does an upstream contract provide inputs that could fail downstream require checks?

False Positives

• The require condition exactly matches the specification
• The strictness is intentional and documented
• The error message is omitted in a pre-0.8.4 contract for gas optimization (custom errors not yet available)

Remediation

• Verify each require condition against the specification: > vs >=, < vs <=
• Add descriptive error messages or use custom errors (Solidity >=0.8.4)
• For external call validations, use SafeERC20 or similar wrappers that handle non-standard return values

function withdraw(uint256 amount) external {
    require(balances[msg.sender] >= amount, "insufficient balance");
    balances[msg.sender] -= amount;
    payable(msg.sender).transfer(amount);
}

// Solidity >=0.8.4: custom errors for gas efficiency
error InsufficientBalance(uint256 available, uint256 requested);

function withdrawV2(uint256 amount) external {
    if (balances[msg.sender] < amount)
        revert InsufficientBalance(balances[msg.sender], amount);
    balances[msg.sender] -= amount;
    payable(msg.sender).transfer(amount);
}