AI Arena - Velislav4o's results

Lines of code

https://github.com/code-423n4/2024-02-ai-arena/blob/cd1a0e6d1b40168657d1aaee8223dc050e15f8cc/src/FighterFarm.sol#L233-L262

Vulnerability details

Impact

The redeemMintPass function permits users to arbitrarily set the iconsTypes attribute of newly minted 'fighters' during the redemption process. This allows them to bypass an intended association between burned 'mintPass' metadata and generated fighter properties. The developer has confirmed this behavior is unintentional.

Proof of Concept

1. An attacker holds a 'mintPass' with a common, undesirable iconType of low market value.

2. They invoke the redeemMintPass function, burning their mintPass.

Crucially, they manually provide an iconsTypes input corresponding to a rare and coveted icon.

3. Since the validation is missing, the contract accepts the manipulated iconsTypes value.

A new 'fighter' is minted, visually representing the rare 'icon' while having originated from a common 'mintPass'.

Tools Used

Manual Review

Recommended Mitigation Steps

Change :

require(
            mintpassIdsToBurn.length == mintPassDnas.length && 
            mintPassDnas.length == fighterTypes.length && 
            fighterTypes.length == modelHashes.length &&
            modelHashes.length == modelTypes.length

to

require(
            mintpassIdsToBurn.length == mintPassDnas.length && 
            mintPassDnas.length == fighterTypes.length && 
            fighterTypes.length == modelHashes.length &&
            modelHashes.length == modelTypes.length &&
            modelTypes.length == iconsTypes.lenght

Assessed type

Invalid Validation

Lines of code

https://github.com/code-423n4/2024-02-ai-arena/blob/cd1a0e6d1b40168657d1aaee8223dc050e15f8cc/src/RankedBattle.sol#L439

Vulnerability details

Impact

This vulnerability allows users to strategically minimize their staking amounts, enabling them to participate in the reward system without genuine risk. This undermines the core concept of risk vs. reward within the protocol.

Proof of Concept

Let's imagine that Alice wants to play Ranked Battle but she decide to stake 1 wei to remove risk of losing NRN The game dose the calculation :  curStakeAtRisk = (bpsLostPerLoss * (amountStaked[tokenId] + stakeAtRisk)) / 10**4;

let's imagine that bpsLostPerLoss is 500 and amountStaked[tokenId] is 1 wei and stakeAtRisk is 10000 wei that mean that the calculation goes

500 * (0+ 10000)) / 10000 = 0

Tools Used

Manual Review

Recommended Mitigation Steps

Enforce a minimum threshold for amountStaked[tokenId] that must be surpassed for battle eligibility. This eliminates the zero-risk scenario.

Assessed type

Math

Lines of code

https://github.com/code-423n4/2024-02-ai-arena/blob/f2952187a8afc44ee6adc28769657717b498b7d4/src/FighterFarm.sol#L484-L531

Vulnerability details

Impact

The current implementation of the fighter minting restriction within the _createNewFighter function has a critical defect. Minting limits are naively enforced by checking the target address's balanceOf. This allows attackers to circumvent safeguards by transferring minted fighters away, and continue minting indefinitely.

Proof of Concept

1. Attacker reaches threshold (balanceOf(attackerAddress) == MAX_FIGHTERS_ALLOWED).
2. Attacker transfers a handful of fighters to a freshly created wallet (attackerAddress2).
3. Since balanceOf(attackerAddress) decreases, they can keep using _createNewFighter even after exceeding the expected limit.

Tools Used

Manual Review

Recommended Mitigation Steps

introduce a mapping counter of created fighters. Increment this with each successful _createNewFighter call. Refuse minting when the global counter hits 10 fighters.

Assessed type

Invalid Validation