Lines of code

Vulnerability details

Impact

In the ERC20 contract used to define the interface for tranche tokens the permit function uses ecrecover to verify a signature submitted by the token owner to approve an address to spend its tranche tokens. However there is a well known issue related to signature malleability where if the r and s values are observed they can be used to craft another valid signature on the other side of the elliptic curve (1).

This would allow any attacker that observers a permit call to a LiquidityPool’s share token, as is done in requestRedeemWithPermit to be able to create a new valid signature approving a malicious address which they can use to transfer the tokens to themselves before the redemption request is executed on the centrifuge chain.

Proof of Concept

1. investor calls LiquidityPool::requestRedeemWithPermit passing in a signature to redeem their tranche tokens
2. attacker observers this call and uses the r and s values to craft a new valid signature which they pass by calling permit directly on the tranche token contract
3. attacker transfers permitted funds to their own contract before the request is executed given that requests are only executed at the end of an epoch

Tools Used

Manual review

Recommended Mitigation Steps

Implement the OpenZeppelin ECDSA library in order to restrict signatures to one side of the elliptic curve.

Assessed type

Access Control

The text was updated successfully, but these errors were encountered:

All reactions