Yieldy contest - elprofesor's results

Lines of code

https://github.com/code-423n4/2022-06-yieldy/blob/524f3b83522125fb7d4677fa7a7e5ba5a2c0fe67/src/contracts/Staking.sol#L50-L101

Vulnerability details

Impact

Yieldy implements a warmUpPeriod to prevent new stakers from using freshly minted yieldy tokens in the Staking.sol contract. warmUpPeriod is not initialised in the contract initialisation therefore a user can frontrun when the onlyOwner calls setWarmUpPeriod() in order to stake in order to bypass possible warmUpPeriods.

Proof of Concept

1. onlyOwner deploys the Staking.sol contract
2. onlyOwner calls the setWarmUpPeriod() function
3. Malicious user frontruns transaction in step (2) in order to stake before the warmup period has been set. Therefore the default value of 0 is used and the expiry is set to the current epoch.

Tools Used

1. Manual code review

Recommended Mitigation Steps

1. Implement a default value for warmUpPeriod during initialisation

Lines of code

https://github.com/code-423n4/2022-06-yieldy/blob/524f3b83522125fb7d4677fa7a7e5ba5a2c0fe67/src/contracts/Staking.sol#L439-L444 https://github.com/code-423n4/2022-06-yieldy/blob/524f3b83522125fb7d4677fa7a7e5ba5a2c0fe67/src/contracts/Staking.sol#L465-L477

Vulnerability details

Yieldy implements a warmUpPeriod to prevent new stakers from using freshly minted yieldy tokens. The function stake() uses this warm up period as follows:

        // skip adding to warmup contract if period is 0
        if (warmUpPeriod == 0) {
            IYieldy(YIELDY_TOKEN).mint(_recipient, _amount);
        } else {
            // create a claim and mint tokens so a user can claim them once warm up has passed
            warmUpInfo[_recipient] = Claim({
                amount: info.amount + _amount,
                credits: info.credits +
                    IYieldy(YIELDY_TOKEN).creditsForTokenBalance(_amount),
                expiry: epoch.number + warmUpPeriod
            });

            IYieldy(YIELDY_TOKEN).mint(address(this), _amount);
        }

On line 443 in Staking.sol the expiry for warmUpInfo[_recipient] is incremented on behalf of any arbitrary user. This expiry info is then used during any claim() function call, to calculate how much Yieldy token to transfer from the base contract to the recipient.

If a malicious user was to continuously send a single token every warmUpPeriod epochs for staking on behalf a victim, they could continuously deny any victim the right to retrieve their Yieldy tokens and therefore cause a targeted denial of service.

Proof of Concept

1. User has stakes staking tokens using the stake() function. This function mints Yieldy tokens and transfers them to the Staking.sol contract as a temporary custodian until after the expiry period has elapsed.
2. User is then allotted a time of warmUpPeriod before they can call the claim() and retrieve their yieldy tokens.
3. In the next epoch, a malicious user stakes a single token on behalf of a user effectively pushing the expiry back by another warmUpPeriod time frame.
4. If the victim calls the claim() function, the function will revert due to the check in isClaimAvailable() since epoch.number < info.expiry

If this attack is repeated the victim will not be able to withdraw any staking tokens until the attacker has finished.

Recommended Mitigation Steps

Ensure that warmup period is only set on new stakers, or prevent arbitrary staking from impacting the expiry of existing stakers.