I have identified a potential vulnerability related to the feeAmount calculation in the instantRedeemWithPxEth function.
Vulnerability:
The instantRedeemWithPxEth function calculates the feeAmount based on the assets parameter, which is provided by the user. This calculation does not include any upper limit, making it susceptible to an integer overflow attack. An attacker can exploit this vulnerability to create a large feeAmount, leading to an overflow, and eventually, the postFeeAmount can become zero, allowing the attacker to redeem all the pxETH without paying any fees.
Impact:
An attacker can exploit this vulnerability to drain the pxETH balance from the contract without paying the required fees, resulting in potential loss of funds.
Exploitation:
An attacker can create a malicious transaction with an extremely large assets value to trigger an integer overflow in the feeAmount calculation. This will lead to a zero or near-zero postFeeAmount, allowing the attacker to redeem all the pxETH without paying any fees.
Recommendation:
To mitigate this vulnerability, implement a maximum limit on the feeAmount based on the assets parameter. This can be done by either using the maxFees mapping to check for any predefined maximum fees or by calculating the maximum allowed fee amount based on the remaining pxETH in the contract.
Here is an example of how to implement the fix:
Update the instantRedeemWithPxEth function to calculate the maxFeeAmount:
Lines of code
https://github.com/redacted-cartel/pirex-eth-contracts/blob/11f30c7e35b67d45deefe405c22a30f352bc5b21/src/PirexEth.sol#L460
Vulnerability details
I have identified a potential vulnerability related to the
feeAmount
calculation in theinstantRedeemWithPxEth
function.Vulnerability:
The
instantRedeemWithPxEth
function calculates thefeeAmount
based on theassets
parameter, which is provided by the user. This calculation does not include any upper limit, making it susceptible to an integer overflow attack. An attacker can exploit this vulnerability to create a largefeeAmount
, leading to an overflow, and eventually, thepostFeeAmount
can become zero, allowing the attacker to redeem all thepxETH
without paying any fees.Impact:
An attacker can exploit this vulnerability to drain the
pxETH
balance from the contract without paying the required fees, resulting in potential loss of funds.Exploitation:
An attacker can create a malicious transaction with an extremely large
assets
value to trigger an integer overflow in thefeeAmount
calculation. This will lead to a zero or near-zeropostFeeAmount
, allowing the attacker to redeem all thepxETH
without paying any fees.Recommendation:
To mitigate this vulnerability, implement a maximum limit on the
feeAmount
based on theassets
parameter. This can be done by either using themaxFees
mapping to check for any predefined maximum fees or by calculating the maximum allowed fee amount based on the remainingpxETH
in the contract.Here is an example of how to implement the fix:
instantRedeemWithPxEth
function to calculate themaxFeeAmount
:feeAmount
is less than or equal to themaxFeeAmount
before proceeding with the redemption process:By implementing this fix, you can prevent the integer overflow attack and secure the smart contract against potential fee manipulation.