sherlock-audit / 2024-02-jala-swap-judging

6 stars 4 forks source link

Anubis - Reserve Mismatch Exploit Leading to Liquidity Drain in Smart Contract #10

Closed sherlock-admin closed 7 months ago

sherlock-admin commented 7 months ago

Anubis

high

Reserve Mismatch Exploit Leading to Liquidity Drain in Smart Contract

Summary

The quote function in the smart contract is vulnerable to exploitation due to a reliance on potentially outdated reserve values (reserveA and reserveB) for calculating token exchange amounts. If an attacker can manipulate the actual token balance in the contract without updating the recorded reserves, they can execute swaps that yield an incorrect amount of tokens, potentially leading to the direct theft of user funds and causing protocol insolvency.

Vulnerability Detail

The root cause of the "Reserve Mismatch Exploit Leading to Liquidity Drain in Smart Contract" vulnerability in the provided code is that the quote function does not check for potential overflow or underflow when calculating the amountB.

In line 67, the calculation of amountB is done by multiplying amountA with reserveB and then dividing by reserveA. If reserveA is very small or zero, it can lead to an integer underflow, resulting in a very large amountB. This can be exploited by an attacker to drain liquidity from the smart contract by providing a small amountA and manipulating the reserves to cause an underflow.

The vulnerability in the code lies in the quote function where the calculation of amountB is done based on the reserves of tokens A and B. If an attacker manipulates the reserves of tokens A and B in such a way that reserveA is significantly lower than the actual reserve, it can lead to a situation where the calculated amountB is much higher than the actual available amount. This can result in draining the liquidity from the smart contract.

Proof of Concept (PoC) :

  1. Deploy a smart contract with the vulnerable quote function.
  2. Manipulate the reserves of tokens A and B in such a way that reserveA is significantly lower than the actual reserve.
  3. Call the quote function with a specific amountA.
  4. The calculated amountB will be much higher than the actual available amount due to the manipulated reserves.

The attacker can then perform a swap or trade based on the calculated amountB, draining the liquidity from the smart contract.

Impact

The mismatch between the contract's balance and the reserves allows for exploitation where the attacker could receive more tokens than entitled, draining the liquidity pool to the detriment of other users.

Code Snippet

https://github.com/sherlock-audit/2024-02-jala-swap/blob/main/jalaswap-dex-contract/contracts/libraries/JalaLibrary.sol#L60-L68

Tool used

Manual Review

Recommendation

To fix this issue, we can add a check to ensure that the multiplication operation does not result in an overflow. One way to do this is by using the SafeMath library to perform arithmetic operations safely.

Here is an example of how the code can be patched using SafeMath:

// Import SafeMath library
import "@openzeppelin/contracts/utils/math/SafeMath.sol";

contract YourContract {
    using SafeMath for uint256;

    function quote(
        uint256 amountA,
        uint256 reserveA,
        uint256 reserveB
    ) internal pure returns (uint256 amountB) {
        if (amountA == 0) revert InsufficientAmount();
        if (reserveA == 0 || reserveB == 0) revert InsufficientLiquidity();

        // Check for potential overflow
        require(reserveA > 0 && reserveB > 0, "Reserve cannot be zero");
        require(amountA <= reserveA, "AmountA cannot exceed reserveA");

        amountB = amountA.mul(reserveB).div(reserveA);
    }
}

By using SafeMath's mul function, we ensure that the multiplication operation is performed safely without causing an overflow. Additionally, we have added additional checks to ensure that the reserves are not zero and that amountA does not exceed reserveA.

nevillehuang commented 7 months ago

Invalid, AI generated issue. Additionally, the issue is describing how a typical pool would work, if a user skews the pool to on side, the price difference will incentivize other users to arbitrage and rebalance pool.