PoolTogether micro contest #1 - shw's results

Handle

shw

Vulnerability details

Impact

The approveMax function of MStableYieldSource calls the safeApprove function to set the allowance to the maximum. However, at the time of call, the allowance should be non-zero since it was set to the maximum in the constructor function. The non-zero allowance would cause the safeApprove function to revert because of a require check in the OpenZeppelin's implementation (see the following link).

Proof of Concept

Referenced code: MStableYieldSource.sol#L61-L65

OpenZeppelin - SafeERC20.sol#L52-L55

Recommended Mitigation Steps

Use safeIncreaseAllowance to increase the allowance to the maximum instead (as used in the approveMaxAmount function of SwappableYieldSource).

Handle

shw

Vulnerability details

Impact

The supplyTokenTo function of SwappableYieldSource assumes that amount of _depositToken is transferred to itself after calling the safeTransferFrom function (and thus it supplies amount of token to the yield source). However, this may not be true if the _depositToken is a transfer-on-fee token or a deflationary/rebasing token, causing the received amount to be less than the accounted amount.

Proof of Concept

Referenced code: SwappableYieldSource.sol#L211-L212

Recommended Mitigation Steps

Get the actual received amount by calculating the difference of token balance before and after the transfer. For example, re-writing line 211-212 to:

uint256 balanceBefore = _depositToken.balanceOf(address(this));
_depositToken.safeTransferFrom(msg.sender, address(this), amount);
uint256 receivedAmount = _depositToken.balanceOf(address(this)) - balanceBefore;
yieldSource.supplyTokenTo(receivedAmount, address(this));