The signature used in the TimelockTokenPool.withdraw function might be reused since the signed message doesn't include nonce and deadline

[c4-bot-5]

Lines of code

https://github.com/code-423n4/2024-03-taiko/blob/f58384f44dbf4c6535264a472322322705133b11/packages/protocol/contracts/team/TimelockTokenPool.sol#L170

Vulnerability details

The TimelockTokenPool contract allows for token withdrawals on behalf of users by utilizing a permit-like signature:

function withdraw(address _to, bytes memory _sig) external {
    if (_to == address(0)) revert INVALID_PARAM();
    bytes32 hash = keccak256(abi.encodePacked("Withdraw unlocked Taiko token to: ", _to));
    address recipient = ECDSA.recover(hash, _sig);
    _withdraw(recipient, _to);
}

This function might be called multiple times as the tokens are unlocked gradually. The issue arises from the fact that the signed message doesn't include deadline and nonce. It means that anyone can reuse this signature and replay a withdrawal transaction.

It's not much of an issue if the user manages approvals meticulously, but users often opt for unlimited approvals to save on gas. In this case, an attacker is still unable to steal anything, but they can replay a withdrawal transaction without the user's consent. This is quite concerning, as this transaction might essentially involve swapping costToken for taikoToken and the user might have some other use for costToken in mind. There also might be extreme cases where the user attempts to prevent liquidation using costToken, only to be front-run by the attacker.

This issue becomes even more severe if the _to address is compromised. In such a scenario, an attacker can get taikoToken at the expense of the user. The issue becomes more likely because of the following:

• Users might not think that the signature produced some time ago can be reused since such kinds of permits usually include nonce and deadline and can't be reused;
• Users have no means to revoke the signature, and the only way to protect themselves from this attack is to execute both costToken approval and withdrawal within a single transaction which is possible but isn't simple and obvious for the common user.

Impact

An attacker can reuse a signature to execute an action without the user's consent. In some cases it allows the attacker to steal user's funds.

Proof of Concept

-

Tools Used

Manual Review

Recommended Mitigation Steps

Consider adding a nonce and deadline to the signed message. Additionally, consider exposing a function that marks the current nonce as used, providing a means for the user to revoke signatures.

Assessed type

Invalid Validation

[c4-pre-sort]

minhquanym marked the issue as duplicate of #60

[c4-judge]

0xean marked the issue as satisfactory

[c4-judge]

0xean changed the severity to 3 (High Risk)