BetFin security record

The `refundSingleBet` function in the `LiveRoulette` contract suffers from an vulnerability due to the lack of validation on the `_bet` parameter. This allows an attacker to create a malicious bet (`LiroBet`) and exploit the refund mechanism to steal funds from the `LiveRoulette` contract, effectively draining the contract's assets. ```solidity function refundSingleBet(address _bet) external { // Approve the bet amount token.approve(address(singlePlayerTable), LiroBet(_bet).getAmount()); // Refund the bet singlePlayerTable.refund(_bet); } ``` The function `refundSingleBet` does not validate whether the `_bet` address represents, for example, a **legitimate bet** created by the `SinglePlayerTable` contract. The current implementation simply approves the corresponding amount of BET tokens for the `_bet` contract and calls the `refund` function on the `singlePlayerTable` contract. As a result, an attacker can drain the entire balance of BET tokens from the `LiveRoulette` contract by exploiting the refund mechanism.

The `placeBet()` function in `LuckeyRound` can be directly called within `LuckeyRound` without going through the `placeBet()` function in `partner`. This allows any user to place bets without transferring token and to select any length of `Offset`. Additionally, this could result in a situation where there are not enough tokens in the contract to transfer to the winner, causing the chainlink VRF `rawFulfillRandomWords()` call to fail. Consequently, all bets for that round will be locked in the contract.

The use of nested loops (including the loops in `getBitMapPayout`), numerous contract calls, and extensive memory allocation(including the memory allocation in `getBitMapPayout`) in `getPossibleWin` results in substantial gas consumption: `Table.sol` ```solidity=46 function getPossibleWin(Library.Bet[] memory _bitmaps) public view returns (uint256, uint256) { uint256 maxPossible = 0; uint256 winNumber = 42; uint256 count = _bitmaps.length; for (uint256 i = 0; i <= 36; i++) { uint256 possible = 0; for (uint256 k = 0; k < count; k++) { uint256 amount = _bitmaps[k].amount; uint256 bitmap = _bitmaps[k].bitmap; (uint256 payout,,) = getBitMapPayout(bitmap); if (bitmap & (2 ** i) > 0) { possible += amount * payout + amount; } if (possible > maxPossible) { maxPossible = possible; winNumber = i; } } } return (maxPossible, winNumber); } ``` In the `MultiplayerTable`, excessive gas consumption can cause `placeBet()` to reach the block gas limit, preventing users from placing bets even when the number of bets is far below `MAX_BETS`. Furthermore, since `getBitMapPayout()` does not revert when an invalid bitMap is passed: `Table.sol` ```solidity=108 function getBitMapPayout(uint256 bitmap) public view returns (uint256, uint256, uint256) { // return invalid bitmap if (bitmap == 0) { return (0, 0, 0); } // check for straight 0,1,2,3...36 if (bitmap & (bitmap - 1) == 0) { return (35, limits["STRAIGHT"].min, limits["STRAIGHT"].max); } // check for corner if (isCorner(bitmap)) { return (8, limits["CORNER"].min, limits["CORNER"].max); } // check for row if (isRow(bitmap)) { return (11, limits["ROW"].min, limits["ROW"].max); } // check for split if (isSplit(bitmap)) { return (17, limits["SPLIT"].min, limits["SPLIT"].max); } // get limit string memory name = payouts[bitmap]; return (limits[name].payout, limits[name].min, limits[name].max); } ``` An attacker can attach multiple bets within a single `placeBet()` call, with each bet having an amount of 0 and an invalid `bitMap` value (e.g., 30, which comprises bets on 1, 2, 3, and 4) to reduce costs. This can quickly result in a DoS, preventing others from calling `placeBet()`. In such cases, if the official team does not actively call the `spin()` function to settle the game round, others would lack motivation to call `spin()`. The attacker could then exploit the `Users Can Front-Run to Revoke Unfavorable Game Results After Refund Waiting Period` vulnerability to frontrun after the refund waiting period, ensuring that each bet they place does not result in a disadvantageous outcome for them. From the chain perspective, on Ethereum, high gas costs could make the returns significantly lower than the transaction fees, discouraging users from participating in the game. However, on Polygon, the gas fee issue would be greatly alleviated.

The `spin()` function in `MultiplayerTable` lacks the `onlyLiro` modifier: `MultiPlayerTable.sol` ```solidity=84 function spin(uint256 _round) external returns (bytes memory) { // check if round is older than the current round require(_round < getCurrentRound(), "MP01"); // check if round status is 1 require(roundStatus[_round] == 1, "MP04"); // check if the bank is above the maximum limit require(liro.token().balanceOf(address(this)) >= roundPossibleWin[_round], "MP05"); // should not happen roundStatus[_round] = 2; return abi.encode(false, address(this), _round); } ``` Anyone can directly call `MultiplayerTable` `spin()` to change `roundStatus[_round]`, preventing others from using `LiveRoulette` `spin()` to send an event requesting randomness. This renders the round invalid, leaving users only able to request a refund after the refund waiting period.

In the `SinglePlayerTable` contract, there is a potential issue where unclaimed possible win tokens are not returned to the staking contract if the player does not win. This could result in tokens being locked in the `SinglePlayerTable` contract indefinitely, which should otherwise be returned to the staking contract for future use. In the `placeBet` function, a bet is placed, and the possible win amount is calculated. The contract then reserves the possible win tokens from the staking contract by transferring them to the `SinglePlayerTable` contract. This amount is held in the contract so that, if the player wins, the win can be paid out immediately. If the player wins, the contract does the following in the `result` function: 1. Transfers the win amount to the player. 2. Returns any remaining unclaimed amount (i.e., `rest`) from the possible win back to the staking contract. ```solidity=60 if (winAmount > 0) { // set the result bet.setResult(winAmount); // transfer the win amount liro.token().transfer(bet.getPlayer(), winAmount); // transfer rest to staking uint256 rest = betPossibleWin[_bet] - winAmount; if (rest > 0) { liro.token().transfer(address(liro.staking()), rest); } // transfer initial bet amount to staking liro.token().transferFrom(address(liro), address(liro.getStaking()), bet.getAmount()); } else { // set the result bet.setResult(0); } ``` If a player loses, the entire possible win amount remains locked in the `SinglePlayerTable` contract. Over time, as more players lose, this could accumulate a significant amount of tokens locked in the contract, which should ideally be returned to the staking contract for future use. Moreover, if the bet is lost, the bet tokens are not transferred to the staking contract and will remain locked in the `LiveRoulette` contract.

In the `LiveRoulette` contract, there is a refund mechanism that allows users to call a function to receive a refund if a round has not been settled for a prolonged period. However, this function is only applicable to the `MultiPlayerTable`: ```solidity=111 function refund(address _table, uint256 _round) external { // check if table exists require(tables[_table], "LR03"); token.approve(_table, MultiPlayerTable(_table).getRoundBank(_round)); // execute refund MultiPlayerTable(_table).refund(_round); } ``` The `singlePlayerTable` may also encounter cases where a game cannot be settled or is delayed for a prolonged period. For example, this could happen if the project team fails to deposit sufficient funds into Gelato's `1balance` contract, preventing the system from invoking the `fulfillRandomness` function in `LiveRoulette`. In this situation, the single player’s bet will be locked in the contract, unable to be withdrawn.

Before `core` calls `placeBet()` function, it will determine whether to charge a fee based on `getFeeType()` in the `Stones` contract. In core, when `getFeeType()==0`, the fee is charged and totalAmount will be deducted from the fee before being transferred to the `Stones` contract. When `getFeeType==1`, totalAmount is fully transferred to the `Stones` contract. In this contract, the result of the `getFeeType()` function is `1`, indicating no fee is charged. However, in the `executeResult()` function, `roundBank`(the total amount of tokens for a specified round) is deducted from the fee before calculating `winAmount` and `bonusAmount`. We would like to confirm with the team if this is the intended design. If so, the fee amount will be locked in the contract.

In `placeBet()` of `MultiplayerTable`, limit the `maxPossibleWin` for this round to no more than 5% of the tokens held in staking(`allowedToWin`): `MultiPlayerTable.sol` ```solidity=69 (uint256 maxPossibleWin,) = getPossibleWin(roundBitmaps[_round]); // check if the possibleWin is above the maximum limit // get allowed to win uint256 allowedToWin = liro.token().balanceOf(liro.getStaking()) * 5 / 100; // check if the possible win is allowed require(allowedToWin >= maxPossibleWin, "MP03"); // update round status if needed if (roundStatus[_round] == 0) { roundStatus[_round] = 1; } uint256 diff = maxPossibleWin - roundPossibleWin[_round]; roundPossibleWin[_round] = maxPossibleWin; ``` However, all bet funds prior to this `placeBet()` have already been transferred from the `staking` contract into the `MultiplayerTable` contract during previous calls: `LiveRoulette.sol` ```solidity=97 (address bet, uint256 diff) = table.placeBet(data); // reserve the amount from staking or send back if (diff > 0) { // reserve funds from staking staking.reserveFunds(uint256(diff)); // send the reserved funds to the table require(token.transfer(_table, uint256(diff)), "LR07"); } ``` Since the `allowedToWin` calculation does not account for this portion of funds, the funds of this game round in the `MultiplayerTable` contract are less than 5%.

In the `constructor`, the value of `_interval` will be assigned to the immutable state variable `interval` without any value validation. The value should be set to greater than or at least equal to a specified time interval (for example, one hour) to prevent the occurrence of invalid rounds. For instance, if the time is less than 12 seconds（one block interval), invalid rounds will certainly occur.

There should always be events emitted in the sensitive functions that are controlled by centralization roles.