Security: Risky First deposit in function _sharesForAmount

[smartsmartsec]

Attack type

Remote

Impact

• Denial of Service
• Other: The lack of share distribution in situations where totalPooledEther is zero may lead to unfair treatment of users, disrupting the normal operation and expected behavior of the contract.

Affected component(s)

function _sharesForAmount in LiquidityPool.sol

Attack vector(s)

This vulnerability is triggered when a user attempts to deposit into the contract when the totalPooledEther is zero, an edge case that may not typically be considered malicious but results in unexpected behavior.

Suggested description of the vulnerability for use in the CVE

The sharesForAmount function in the smart contract fails to handle cases where the totalPooledEther is zero adequately. Instead of allowing for a minimum share allocation, it returns zero shares irrespective of the amount deposited. This behavior leads to a denial of service as users do not receive any shares for their deposits when totalPooledEther is zero, deviating from typical expectations and potentially leading to a loss of functionality and trust in the smart contract.

Discoverer(s)/Credits

xFuzz

Proposed Solution

To address this vulnerability, it is recommended that the smart contract include a logic check to handle the case when totalPooledEther is zero. Possible solutions could involve initializing the contract with a minimal amount of ether to prevent the total pooled ether from being zero or modifying the share calculation logic to ensure that shares are distributed even when the total pooled ether is initially zero. These changes will help maintain the integrity and expected functionality of the contract.

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