Platform: Code4rena
Start Date: 09/02/2024
Pot Size: $60,500 USDC
Total HM: 17
Participants: 283
Period: 12 days
Judge:
Id: 328
League: ETH
Rank: 198/283
Findings: 3
Award: $3.15
π Selected for report: 0
π Solo Findings: 0
π Selected for report: Aamir
Also found by: 0rpse, 0x11singh99, 0x13, 0xAlix2, 0xAsen, 0xBinChook, 0xCiphky, 0xE1, 0xKowalski, 0xLogos, 0xWallSecurity, 0xaghas, 0xbranded, 0xlemon, 0xlyov, 0xpoor4ever, 0xprinc, 0xvj, ADM, Aymen0909, BARW, Bauchibred, Breeje, CodeWasp, DMoore, DeFiHackLabs, Draiakoo, Fulum, GhK3Ndf, Greed, Jorgect, Josh4324, Kalogerone, KmanOfficial, Krace, Limbooo, McToady, MidgarAudits, MrPotatoMagic, PedroZurdo, Pelz, Ryonen, SovaSlava, SpicyMeatball, Tendency, Timenov, ZanyBonzy, _eperezok, al88nsk, alexxander, alexzoid, aslanbek, blutorque, btk, cartlex_, cats, csanuragjain, deadrxsezzz, denzi_, devblixt, dimulski, djxploit, erosjohn, evmboi32, fnanni, grearlake, haxatron, hulkvision, immeas, israeladelaja, jaydhales, jesjupyter, jnforja, josephdara, juancito, kiqo, klau5, korok, krikolkk, ktg, kutugu, ladboy233, lil_eth, m4ttm, matejdb, merlinboii, n0kto, ni8mare, novamanbg, nuthan2x, oualidpro, pa6kuda, peter, petro_1912, pkqs90, pynschon, sandy, sashik_eth, shaflow2, shaka, sobieski, soliditywala, solmaxis69, stackachu, tallo, thank_you, tpiliposian, ubl4nk, visualbits, vnavascues, web3pwn, xchen1130, zhaojohnson
0.0037 USDC - $0.00
https://github.com/code-423n4/2024-02-ai-arena/blob/main/src/GameItems.sol#L291
Game items added to the game have the transferable field, which indicates whether an owner of such item can transfer the given item. This is enforced in the safeTransferFrom function, where the function checks if the item can be transferred and reverts if it can not. However, this can be circumvented by using the other function of ERC-1155, safeBatchTransferFrom
.
The players are able to transfer non-transferable game items.
See the following test added to test/GameItems.t.sol
.
function testSafeBatchTransferNonTransferrableItem() public { _fundUserWith4kNeuronByTreasury(_ownerAddress); vm.prank(_ownerAddress); _gameItemsContract.mint(0, 2); //paying 2 $NRN for 2 batteries _gameItemsContract.adjustTransferability(0, false); (, , bool transferable, , , ) = _gameItemsContract.allGameItemAttributes(0); assertEq(transferable, false); // safe transfer form will revert as expected since the item is not transferable vm.expectRevert(); _gameItemsContract.safeTransferFrom(_ownerAddress, msg.sender, 0, 2, ""); uint256[] memory ids = new uint256[](1); ids[0] = 0; uint256[] memory amounts = new uint256[](1); amounts[0] = 2; // safe batch transfer from will not revert _gameItemsContract.safeBatchTransferFrom( _ownerAddress, msg.sender, ids, amounts, "" ); uint ownerBalance = _gameItemsContract.balanceOf(_ownerAddress, 0); uint callerBalance = _gameItemsContract.balanceOf(msg.sender, 0); // balances have changed assertEq(ownerBalance, 0); assertEq(callerBalance, 2); }
Manual review
Consider adding the check whether the item is transferable to either the _beforeTokenTransfer
function or the safeBatchTransferFrom
function.
Token-Transfer
#0 - c4-pre-sort
2024-02-22T03:42:47Z
raymondfam marked the issue as sufficient quality report
#1 - c4-pre-sort
2024-02-22T03:42:55Z
raymondfam marked the issue as duplicate of #18
#2 - c4-pre-sort
2024-02-26T00:27:45Z
raymondfam marked the issue as duplicate of #575
#3 - c4-judge
2024-03-05T04:47:39Z
HickupHH3 changed the severity to 3 (High Risk)
#4 - c4-judge
2024-03-05T04:52:15Z
HickupHH3 marked the issue as satisfactory
π Selected for report: Abdessamed
Also found by: 0rpse, 0xAlix2, 0xAsen, 0xCiphky, 0xlemon, 0xmystery, 0xvj, ADM, Aamir, Archime, BARW, DarkTower, Draiakoo, FloatingPragma, JCN, McToady, MrPotatoMagic, OMEN, PetarTolev, Ryonen, SpicyMeatball, Tendency, VAD37, Velislav4o, VrONTg, Zac, adamn000, ahmedaghadi, alexxander, alexzoid, bhilare_, btk, cats, d3e4, denzi_, devblixt, dimulski, evmboi32, fnanni, givn, haxatron, immeas, jesjupyter, juancito, ke1caM, klau5, korok, krikolkk, matejdb, n0kto, niser93, peter, pkqs90, radin100, shaka, sl1, soliditywala, stackachu, stakog, t0x1c, vnavascues, yotov721, zhaojohnson
1.2667 USDC - $1.27
https://github.com/code-423n4/2024-02-ai-arena/blob/main/src/FighterFarm.sol#L233
Anybody with a mint pass can mint the superior Dendroid type of fighter.
The owners of the mint pass can create a fighter by calling the redeemMintPass function, which will burn their mint pass NFT. However, the type of the fighter to be minted is passed as a parameter, making it possible for the owner to set it to Dendroid, which is a superior, rare type of fighter. Since there is no restriction regarding Dendroid minting, this will make every mint pass owner able to create a superior type of fighter.
Manual review
Consider adding some kind of restriction for Dendroid minting.
Invalid Validation
#0 - c4-pre-sort
2024-02-22T07:33:34Z
raymondfam marked the issue as sufficient quality report
#1 - c4-pre-sort
2024-02-22T07:33:43Z
raymondfam marked the issue as duplicate of #33
#2 - c4-pre-sort
2024-02-26T00:53:05Z
raymondfam marked the issue as duplicate of #1626
#3 - c4-judge
2024-03-05T10:56:45Z
HickupHH3 marked the issue as satisfactory
π Selected for report: ktg
Also found by: 0xCiphky, 0xDetermination, 0xRiO, 0xWallSecurity, 0xlemon, 0xvj, AlexCzm, BARW, Blank_Space, Draiakoo, FloatingPragma, Giorgio, Matue, McToady, MrPotatoMagic, Silvermist, SpicyMeatball, Tendency, Topmark, Tumelo_Crypto, _eperezok, agadzhalov, ahmedaghadi, alexxander, aslanbek, cats, d3e4, denzi_, dutra, evmboi32, fnanni, givn, handsomegiraffe, haxatron, immeas, juancito, ke1caM, kiqo, klau5, krikolkk, niser93, peter, petro_1912, pkqs90, rspadi, sl1, stakog, visualbits, vnavascues, yotov721
1.876 USDC - $1.88
https://github.com/code-423n4/2024-02-ai-arena/blob/main/src/MergingPool.sol#L139
Users can circumvent the boundaries of fighter weight
and element
attributes, which might lead to undefined behavior.
A user can call the claimRewards function to claim their rewards and mint a new fighter. However, the user can specify the customAttributes, that is later passed to the mintFromMergingPool call. The value of this parameter is not validated neither in the original function nor in the mintFromMergingPool function. This means that the values can be anywhere in the range from 0
to type(uint256).max
. Custom attributes are passed to createNewFighter
here, where these are assigned first to local variables and then a new fighter is created with these values. However, when creating a fighter using another method accessible, the values are bounded as we can see here (the boundaries were also confirmed by the sponsor in a private conversation). Since these values are used off-chain to calculate the attributes of the fighters, we can not determine the impact of this, but the code and documentation suggest such situations should not be possible to occur and might lead to undefined behavior.
Manual review
Consider adding a check or a mechanism that will ensure that these values stay within the intended boundaries.
Invalid Validation
#0 - c4-pre-sort
2024-02-24T08:54:19Z
raymondfam marked the issue as insufficient quality report
#1 - c4-pre-sort
2024-02-24T08:54:28Z
raymondfam marked the issue as duplicate of #226
#2 - c4-judge
2024-03-11T10:24:24Z
HickupHH3 marked the issue as satisfactory