Frontrun setRJoe

[code423n4]

Handle

pauliax

Vulnerability details

Impact

Anyone can initialize a new rJOE token. The first time rJoe token is set in the constructor of the contract RocketJoeFactory, but there is also a function called setRJoe to change this address later:

  function setRJoe(address _rJoe) external override onlyOwner {
      IRocketJoeToken(_rJoe).initialize();
      rJoe = _rJoe;
      emit SetRJoe(_rJoe);
  }

The problem is when this new token is deployed and setRJoe is called in a separate transaction. This makes it vulnerable to the frontrunning attack: 1) owner deploys new rJoe token 2) owner calls setRJoe on RocketJoeFactory, but a malicious actor monitors the mempool and frontruns this tx by directly calling initialize() on this new token contract setting himself as the factory.

While I can't make assumptions that this will always be the case, based on the current implementation of RocketJoeToken, the initialize() function is unprotected, thus the first one to call it is assigned as a factory.

Recommended Mitigation Steps

Maybe later implementations will have an auth protection as the factory address will be known upfront, but I just wanted you to be aware of this potential attack, so you can actor accordingly and prevent a new rJoe token get hijacked by a malicious actor.

[cryptofish7]

Duplicate of #155

[dmvt]

Duplicate of #8