Platform: Code4rena
Start Date: 03/05/2022
Pot Size: $30,000 USDC
Total HM: 6
Participants: 93
Period: 3 days
Judge: gzeon
Id: 118
League: ETH
Rank: 30/93
Findings: 2
Award: $276.82
🌟 Selected for report: 0
🚀 Solo Findings: 0
🌟 Selected for report: Kulk0
Also found by: 0x1f8b, 0xDjango, BowTiedWardens, Dinddle, broccolirob, defsec, dirk_y, hyh, rajatbeladiya, throttle, unforgiven
The docs say there is a cap on how many tokens the project team can mint, however there are no checks or tracking implemented in the teamSummon function to enforce that limit. An admin calling that function could accidentally or maliciously exceed the amount of tokens allotted to the team at any point.
At the start of the public sale, eager team member Bob tries to call teamSummon(0xb0b..., 333).
Bob adds an extra 3 to the second argument and accidentally sends teamSummon(0xb0b...,3333). Bob successfully mints more than the total team token allocation
Manual analysis
Add a check to make sure team members who summon tokens don't summon more than their allocated share.
#0 - KenzoAgada
2022-06-06T05:38:46Z
Duplicate of #104.
🌟 Selected for report: defsec
Also found by: 0v3rf10w, 0x1f8b, 0x4non, 0x52, 0xDjango, 0xf15ers, 0xkatana, 0xliumin, AuditsAreUS, BowTiedWardens, CertoraInc, Cr4ckM3, Funen, GimelSec, Hawkeye, IllIllI, Kulk0, M0ndoHEHE, MaratCerby, Picodes, Ruhum, TerrierLover, TrungOre, VAD37, WatchPug, berndartmueller, broccolirob, catchup, cccz, cryptphi, csanuragjain, delfin454000, dirk_y, eccentricexit, ellahi, fatherOfBlocks, gzeon, hake, hansfriese, hickuphh3, horsefacts, hubble, hyh, ilan, joestakey, kebabsec, kenta, kenzo, leastwood, m9800, marximimus, minhquanym, oyc_109, p4st13r4, pauliax, pedroais, peritoflores, plotchy, rajatbeladiya, reassor, rfa, robee, rotcivegaf, samruna, shenwilly, shung, simon135, sorrynotsorry, sseefried, teddav, throttle, tintin, unforgiven, z3s
30.2759 USDC - $30.28
https://github.com/code-423n4/2022-05-runes/blob/060b4f82b79c8308fe65674a39a07c44fa586cd3/contracts/ForgottenRunesWarriorsMinter.sol#L179 https://github.com/code-423n4/2022-05-runes/blob/060b4f82b79c8308fe65674a39a07c44fa586cd3/contracts/ForgottenRunesWarriorsMinter.sol#L139 https://github.com/code-423n4/2022-05-runes/blob/060b4f82b79c8308fe65674a39a07c44fa586cd3/contracts/ForgottenRunesWarriorsMinter.sol#L156-L160
Phase one of the mint doesn't end until phase two begins. Presumably, phase one might not sell out all the available tokens. If this happens finalPrice will not be reassigned from the starting price. There is a mechanism for admins to assign it themselves, however, the assumption is that phase 1 will remain open till phase 2 starts, so there will inevitably be some lag between phase 1 ending and the admins reassigning the finalPrice variable. During the overlapping time interval a claimer will have to pay the start price of 2.5 ether to mint their NFT, instead of the finalPrice of whatever the admins set it to.
Phase 2 timestamp is surpassed by block.timestamp and begins.
Phase 1 ends.
Bob calls mintlistSummon and has to pay 2.5 eth
manual
Don't let mintlistSummon be called till finalPrice is set
#0 - gzeoneth
2022-06-18T17:34:12Z
True but also they have to supply the incorrect msg.value, also well documented. https://github.com/code-423n4/2022-05-runes/blob/060b4f82b79c8308fe65674a39a07c44fa586cd3/contracts/ForgottenRunesWarriorsMinter.sol#L157-L158
// optimistic: save gas by not setting on every mint, but will // require manual `setFinalPrice` before refunds if da falls short
and in README
Known Configuration Required The times all need to be set correctly The finalPrice of the Dutch Auction is used in subsequent phases and it set automatically if the DA sells out. If the DA fails to sell out, the owner needs to set this value manually for the subsequent phases to be priced correctly.
Downgrading to Low / QA.
#1 - gzeoneth
2022-06-18T19:25:33Z
As warden's QA report.