Another lesson from Farcaster.

Studying missed bugs and how to not miss them again is a must. This post is about another cool bug I missed during Farcaster contest.

The code was using OpenZepplin’s SignatureChecker to check if a particular signature is valid:

function verify(address target, bytes sig ...) public returns (bool) {
  return
@>  SignatureChecker.isValidSignatureNow(
      target,
      sig,
      ...
    )
}

Signatures was submitted by a relayer. The system incentives challengers to challenge signatures validity within a challenge period, and rewards them for valid challenges. The interesting thing about isValidSignatureNow() function is this comment:

NOTE: Unlike ECDSA signatures, contract signatures are revocable, and the outcome of this function can thus change through time. It could return true at block N and false at block N+1 (or the opposite).

From an attacker perspective, this is leverage. It’s logic to twist and increase the attack surface. I can write a contract that returns a valid signature for block N (e.g. before challenge period) and an invalid one for block N+1 (e.g. during challenge period). I’m not sure if this is what we call a honeypot but this is def a sweet issue. With this leverage, the attacker starts to ask questions:

1. Can we set target as a contract address? Turns out yes.
2. What’s the worse impact we cause? Turns out we can get challenge reward.

It’s worth mentioning these are 1271 signatures. 1271 signatures basically allow smart contracts to sign txs too, based on any arbitrary logic defined in a isValidSignature() function. This was only a privelege for EOAs pre 1271. I can imagine this was used in this codebase to enable smart contract bots to detect and sign challenges, which makes a lot of sense if you think about it. I took a minute to read the security considerations section which boils down to 1. Forwarding limited gas to isSignatureValid may cause verification to fail and 2. isSignatureValid may be underconstrained as in we may think we defined all the conditions for signature validity except we did not.

This is the contract used in one of the PoCs, simple and sweet:

pragma solidity ^0.8.0;

interface IERC1271 {
  /**
    * @dev Should return whether the signature provided is valid for the provided data
    * @param hash      Hash of the data to be signed
    * @param signature Signature byte array associated with `hash`
    */
  function isValidSignature(bytes32 hash, bytes memory signature) external view returns (bytes4 magicValue);
}

contract FarcasterContractUser is IERC1271 {
  bool public isOn;

  constructor() payable {
      isOn = true;
  }

  function signatureSwitch(bool _isOn) public {
      isOn = _isOn;
  }

  function isValidSignature(bytes32 hash, bytes memory signature) public view returns (bytes4 magicValue) {
      if (isOn) {
          return IERC1271.isValidSignature.selector;
      } else {
          return 0xffffffff;
      }
  }

  fallback() external payable {}
}

If I was the downgradooor judge, I would say a vigil relayer would alywas check for the target address, see if’s a contract one and if so, check for its code before submitting a valid signature. But even with that, the described issue still persists because the attacker can add one more layer of obfuscation by making the contract upgradable and only upgrade it to the malicious version once the relayer submitted the valid signature!