Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Signature Replay Vulnerability in TimelockTokenPool #121

Closed
c4-bot-3 opened this issue Mar 23, 2024 · 2 comments
Closed

Signature Replay Vulnerability in TimelockTokenPool #121

c4-bot-3 opened this issue Mar 23, 2024 · 2 comments
Labels
3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working duplicate-60 edited-by-warden 🤖_60_group AI based duplicate group recommendation satisfactory satisfies C4 submission criteria; eligible for awards

Comments

@c4-bot-3
Copy link
Contributor

c4-bot-3 commented Mar 23, 2024

Lines of code

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

Vulnerability details

Impact

TimelockTokenPool contract has two withdrawal functionality, one that allows withdrawal to self and another that allows withdrawal to a different address.
The latter allows withdrawal to other addresses via a signature, it works by providing a signature and a receiving address on call, on the signature recovery, the returned signer acts as the recipient whose grants will be sent to the receiving _to address.

    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);
    }

The problem here is:

  • Due to the lack of signature expiration or the use of a nonce value, the receiving address can continuously re-use the same signature to withdraw the recipient's accumulated grant before he can.

To Illustrate:

Consider the scenario where Alice, entitled to 200 grants, initially withdraws 100 for herself. She later decides to distribute 50 grants each to Bob and Charlie. Alice then signs a transaction to withdraw her current allowance of 50 grants to Bob. However, days later, when she intends to repeat the process for Charlie, Bob reuses Alice's previous transaction signature, to redirect her intended grant withdrawal to himself, leaving Charlie with either nothing or only a fraction of the intended amount, depending on Alice's remaining allowance at the time of execution.
Bob can continually reuse the same signature to withdraw Alice's grants whenever she's allocated any in the future

  • Final thoughts

From the current implementation, I believe whenever the recipient wishes to withdraw to self, she uses TimelockTokenPool::withdraw() and TimelockTokenPool::withdraw(_to, sig) when she intends to send her withdrawal to a different address. The receiving address could be owned or it might not, but regardless the signature should only be usable once to prevent this issue.
Since the use of this functionality potentially puts the recipient's grants at risk of being stolen, I have labelled this issue to be of a High severity

Proof of Concept

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

Tools Used

Manual Review

Recommended Mitigation Steps

Either add a requirement that ensures the caller is the returned recipient or integrate a nonce value for signatures per recipient.

Assessed type

Error

@c4-bot-3 c4-bot-3 added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working labels Mar 23, 2024
c4-bot-3 added a commit that referenced this issue Mar 23, 2024
@c4-bot-1 c4-bot-1 removed the 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value label Mar 23, 2024
@code4rena-admin code4rena-admin added 3 (High Risk) Assets can be stolen/lost/compromised directly edited-by-warden labels Mar 23, 2024
@c4-bot-11 c4-bot-11 added the 🤖_60_group AI based duplicate group recommendation label Mar 27, 2024
@c4-pre-sort
Copy link

minhquanym marked the issue as duplicate of #60

@c4-judge
Copy link
Contributor

0xean marked the issue as satisfactory

@c4-judge c4-judge added the satisfactory satisfies C4 submission criteria; eligible for awards label Apr 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working duplicate-60 edited-by-warden 🤖_60_group AI based duplicate group recommendation satisfactory satisfies C4 submission criteria; eligible for awards
Projects
None yet
Development

No branches or pull requests

6 participants