Security: Risky First Deposit in function _sharesForDepositAmount

[smartsmartsec]

Attack type

Remote

Impact

• Denial of Service
• Escalation of Privileges

Affected component(s)

function _sharesForDepositAmount in LiquidityPool.sol

Attack vector(s)

The attacker deposits an amount of tokens that precisely matches the tokens already pooled minus any current transaction, thus driving the totalPooledEther to zero.

Suggested description of the vulnerability for use in the CVE

In the affected smart contract, the _sharesForDepositAmount function does not adequately validate input to prevent a scenario where the totalPooledEther can become zero after a new deposit (_depositAmount). If totalPooledEther is zero, the function erroneously allows the last depositor to obtain a disproportionately large amount of the total shares, potentially gaining full control over the assets in the contract. This can occur when the _depositAmount equals the total assets before the transaction minus any ongoing transactions.

Discoverer(s)/Credits

xFuzz

Proposed Solution

It is recommended to implement a check within the _sharesForDepositAmount function to ensure that totalPooledEther cannot be zero after a deposit. Additionally, introducing minimum threshold limits for total pooled ether and deposit amounts could mitigate the risk of such attacks. Developers should also consider utilizing established libraries for handling such critical calculations to avoid similar vulnerabilities.

Reference(s)

• https://github.com/etherfi-protocol/smart-contracts/blob/master/src/LiquidityPool.sol
• https://etherscan.io/address/0x308861A430be4cce5502d0A12724771Fc6DaF216?utm_source=immunefi#code
• https://code4rena.com/reports/2022-01-insure#h-06-the-first-depositor-to-a-pool-can-drain-all-users