in `RouterV2` a usage of `permit` directly in `removeLiquidityWithPermit` and `removeLiquidityETHWithPermit` is susceptible to greifing and constant reverts #28
Description:Description\
The RouterV2 contract contains two functions, removeLiquidityWithPermit and removeLiquidityETHWithPermit, which use the permit function to approve token spending. These functions are vulnerable to a front-running attack that can cause them to revert, denying service to legitimate users.
The vulnerability stems from the fact that these functions unconditionally call the permit function of the pair contract. An attacker can extract the signature parameters from a pending transaction and use them to front-run the original transaction, causing the subsequent legitimate call to fail.
Attack Scenario\
A user calls removeLiquidityWithPermit or removeLiquidityETHWithPermit with valid signature parameters.
An attacker observes this transaction in the mempool.
The attacker extracts the signature parameters (v, r, s) and other relevant data from the pending transaction.
The attacker front-runs the user's transaction by calling the permit function directly on the pair contract with the extracted parameters.
When the original user's transaction is processed, the permit call within the function fails because the permit has already been used, causing the entire transaction to revert.
The user is unable to remove liquidity, effectively being denied service.
This attack can be repeated, consistently preventing users from using these functions.
Github username: -- Twitter username: -- Submission hash (on-chain): 0xe6131252ba2c174278001eb87acd792c14daf5e11afbb9200a22f80b08ce46c8 Severity: medium
Description: Description\ The
RouterV2
contract contains two functions,removeLiquidityWithPermit
andremoveLiquidityETHWithPermit
, which use thepermit
function to approve token spending. These functions are vulnerable to a front-running attack that can cause them to revert, denying service to legitimate users.The vulnerability stems from the fact that these functions unconditionally call the
permit
function of the pair contract. An attacker can extract the signature parameters from a pending transaction and use them to front-run the original transaction, causing the subsequent legitimate call to fail.Attack Scenario\ A user calls removeLiquidityWithPermit or removeLiquidityETHWithPermit with valid signature parameters.
An attacker observes this transaction in the mempool.
The attacker extracts the signature parameters (v, r, s) and other relevant data from the pending transaction.
The attacker front-runs the user's transaction by calling the permit function directly on the pair contract with the extracted parameters.
When the original user's transaction is processed, the permit call within the function fails because the permit has already been used, causing the entire transaction to revert.
The user is unable to remove liquidity, effectively being denied service.
This attack can be repeated, consistently preventing users from using these functions.
Attachments
Proof of Concept (PoC) File
Revised Code File (Optional)