Submitted by MiloTruck
The renounceOwnership() function allows the owner of a LSP0ERC725Account to renounce ownership through a two-step process. When renounceOwnership() is first called, _renounceOwnershipStartedAt is set to block.number to indicate that the process has started:
LSP14Ownable2Step.sol#L159-L167
When renounceOwnership() is called again, the owner is then set to address(0):
LSP14Ownable2Step.sol#L176-L178
However, as _pendingOwner is only deleted in the first call to renounceOwnership(), an owner could regain ownership of the account after the second call to renounceOwnership() by doing the following:
As _pendingOwner is still set to the owners address, they can call acceptOwnership() at anytime to regain ownership of the account.
Even after the renounceOwnership() process is completed, an owner might still be able to regain ownership of an LSP0 account.
This could potentially be dangerous if users assume that an LSP0 account will never be able to call restricted functions after ownership is renounced, as stated in the following comment:
For example, if a protocols admin is set to a LSP0ERC725Account, the owner could gain the communitys trust by renouncing ownership. After the protocol has gained a significant TVL, the owner could then regain ownership of the account and proceed to rug the protocol.
The following Foundry test demonstrates how an owner can regain ownership of a LSP0ERC725Account after renounceOwnership() has been called twice:
Consider deleting _pendingOwner when renounceOwnership() is called for a second time as well:
LSP14Ownable2Step.sol#L176-L178
Call/delegatecall
minhquanym (lookout) commented:
CJ42 (LUKSO) confirmed
