Griefing Attacks¶

Griefing attacks target vulnerabilities in smart contracts, usually in the business logic, and degrade the operation of the system without producing direct profit for the attacker. The goal is disruption, either of general system operations or of a specific critical moment.

The following contract illustrates a typical scenario:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

pragma solidity ^0.8.17;

contract DelayedWithdrawal {
    address beneficiary;
    uint256 delay;
    uint256 lastDeposit;

    constructor(uint256 _delay) {
        beneficiary = msg.sender;
        lastDeposit = block.timestamp;
        delay = _delay;
    }

    modifier checkDelay() {
        require(block.timestamp >= lastDeposit + delay, "Keep waiting");
        _;
    }

    function deposit() public payable {
        require(msg.value != 0);
        // @audit any caller resets the withdrawal delay
        lastDeposit = block.timestamp;
    }

    function withdraw() public checkDelay {
        (bool success, ) = beneficiary.call{value: address(this).balance}("");
        require(success, "Transfer failed");
    }
}

The constructor sets the beneficiary to the deployer's address along with a custom delay, for instance 24 hours. Anyone deposits funds, which become available for withdrawal and transfer to the beneficiary after the configured delay, and each deposit must carry a non-zero amount of ETH.

The opening for a griefing attack is that anyone can call deposit and reset the lastDeposit timestamp. A griefing attacker transfers a minimal amount, one wei, and the resulting timestamp keeps the beneficiary from withdrawing.

The cheapest form of the attack submits a transaction just before the end of the delay period. Frontrunning the beneficiary's calls to withdraw achieves the same denial of service at lower cost, since the attacker pays only when a withdrawal is actually attempted.

Gas Griefing Attacks¶

Insufficient gas griefing is a subset of griefing that affects contracts performing external calls without checking the success return value. The adversary supplies just enough gas for the top-level function to succeed while starving the external call. Under the 63/64 rule, the top-level contract completes its function call and leaves an incomplete state change behind. Contracts executing generic calls, such as relayers and multisig wallets, are the usual targets.

A simplified relayer contract shows the shape:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

pragma solidity ^0.8.17;

contract Relayer {
    mapping (bytes => bool) executed;
    address target;

    function forward(bytes memory _data) public {
        require(!executed[_data], "Replay protection");
        // more code for signature validation in between
        executed[_data] = true;
        // @audit the return value of the external call is never checked
        target.call(abi.encodeWithSignature("execute(bytes)", _data));
    }
}

On failure of the external call, the contract either reverts the whole transaction or continues. This one continues. Once forward completes, the submitted data is marked as executed, which prevents anyone from submitting the same data again.

Any third-party forwarder invokes forward to execute a user's transaction on their behalf. A forwarder calling forward with minimal gas, sufficient for the Relayer contract to succeed but not for the external call, leaves the user's transaction unexecuted and their signature invalidated. The anticipated state change on the target contract never occurs.

Malicious forwarders use the technique to censor user transactions in the Relayer contract permanently. The adversary gains nothing directly, and still disrupts the operation of the smart contract at the victim's expense.