Platform: Code4rena
Start Date: 21/06/2022
Pot Size: $50,000 USDC
Total HM: 31
Participants: 99
Period: 5 days
Judges: moose-code, JasoonS, denhampreen
Total Solo HM: 17
Id: 139
League: ETH
Rank: 26/99
Findings: 2
Award: $380.32
π Selected for report: 0
π Solo Findings: 0
The implementation of Yieldy.transferFrom()
does not checks that _from
currently holds the sent amount _value
.
Although the current compiler reverts while having underflows, having a lack of that check in one of the core functions of the main protocol tokens is a considerable flaw. Currently the only factor that is protecting this function from assigning an infinite amount of tokens triggered by an underflowing transfer is the compiler version.
In order to increase the security on how transfers are going to be performed, it is advisable to check that the _from
account holds the _value
that is desired to be sent.
#0 - toshiSat
2022-07-06T14:33:59Z
duplicate #206
#1 - JasoonS
2022-07-28T12:24:12Z
This is slightly different to #206 - but similar enough I guess.
Basically the transfer method here is unchecked (not checking its return value, not checking the balance, not checking the recipient isn't address(0)
).
#2 - KenzoAgada
2022-08-26T09:14:19Z
This was judged as duplicate of #70 but looks to me more close to #36
π Selected for report: IllIllI
Also found by: 0x1337, 0x1f8b, 0x29A, 0x52, 0xDjango, 0xNazgul, 0xNineDec, 0xc0ffEE, 0xf15ers, 0xmint, Bnke0x0, BowTiedWardens, Chom, ElKu, FudgyDRS, Funen, GalloDaSballo, GimelSec, JC, Kaiziron, Lambda, Limbooo, Metatron, MiloTruck, Noah3o6, Picodes, PumpkingWok, PwnedNoMore, Sm4rty, StErMi, TomJ, TrungOre, UnusualTurtle, Waze, _Adam, aga7hokakological, ak1, antonttc, berndartmueller, cccz, cryptphi, csanuragjain, defsec, delfin454000, dipp, elprofesor, exd0tpy, fatherOfBlocks, hake, hansfriese, hubble, joestakey, kenta, ladboy233, mics, oyc_109, pashov, pedr02b2, reassor, robee, samruna, scaraven, shung, sikorico, simon135, sseefried, tchkvsky, unforgiven, zzzitron
53.1558 USDC - $53.16
Currently Yieldy._mint()
violates the structure of Checks-Effects-Interactions regarding how is computed and controlled the _totalSupply
of each Yieldy asset.
This is the current implementation:
Yieldy.sol 248 function _mint(address _address, uint256 _amount) internal override { 249 require(_address != address(0), "Mint to the zero address"); 250 251 uint256 creditAmount = _amount * rebasingCreditsPerToken; 252 creditBalances[_address] = creditBalances[_address] + creditAmount; 253 rebasingCredits = rebasingCredits + creditAmount; 254 255 _totalSupply = _totalSupply + _amount; 256 257 require(_totalSupply < MAX_SUPPLY, "Max supply"); 258 emit Transfer(address(0), _address, _amount); 259 }
There are many scenarios where violating the Checks-Effects-Interactions design pattern yielded to undesired behavior or unexpected attacks. In order to bring a more secure execution structure, whenever is possible it is advisable to respect the pattern mentioned before.
The line 257 can be moved to line 250 and changed for the following alternative in order to preserve a more secure design pattern:
require(_totalSupply + _amount < MAX_SUPPLY, "Max supply");
#0 - toshiSat
2022-07-06T14:33:23Z
Warden doesn't show any vulnerabilities by changing this and would move to low
#1 - JasoonS
2022-07-28T12:12:25Z
Agreed - low