PoolTogether contest - pauliax's results

A protocol for no loss prize savings on Ethereum

General Information

Platform: Code4rena

Start Date: 17/06/2021

Pot Size: $60,000 USDC

Total HM: 12

Participants: 12

Period: 7 days

Judge: LSDan

Total Solo HM: 8

Id: 14

League: ETH

PoolTogether

Findings Distribution

Researcher Performance

Rank: 5/12

Findings: 3

Award: $2,502.87

🌟 Selected for report: 5

🚀 Solo Findings: 0

Findings Information

🌟 Selected for report: 0xRajeev

Also found by: pauliax

Labels

bug
duplicate
2 (Med Risk)

Awards

786.6464 USDC - $786.65

External Links

Handle

pauliax

Vulnerability details

Impact

_depositInVault in contract YearnV2YieldSource calls safeApprove when the allowance is less than the token balance: if (token.allowance(address(this), address(v)) < token.balanceOf(address(this))) { token.safeApprove(address(v), type(uint256).max); } This does not mean that the current allowance is 0. safeApprove usage: "safeApprove should only be called when setting an initial allowance, or when resetting it to zero. To increase and decrease it, use 'safeIncreaseAllowance' and 'safeDecreaseAllowance'". Reference: https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable/blob/master/contracts/token/ERC20/utils/SafeERC20Upgradeable.sol So this can theoretically start failing once the approval is higher than 0 but lower than the token balance. In practice this will probably never be triggered cuz the initialize function has initially approved the max amount. Rating this as low as the possibility is very unlikely but the impact could be huge (won't be able to deposit tokens in vault).

By the way, overall safeApprove is deprecated, so you may consider replacing it with safeIncreaseAllowance/safeDecreaseAllowance:

  • @dev Deprecated. This function has issues similar to the ones found in * {IERC20-approve}, and its usage is discouraged. * Whenever possible, use {safeIncreaseAllowance} and {safeDecreaseAllowance} instead.

Solution: token.safeApprove(address(v), 0); token.safeApprove(address(v), type(uint256).max); Or completely remove this check to save some gas as the max amount is already approved in the initialize function.

#1 - dmvt

2021-07-31T17:56:57Z

duplicate of #71

Findings Information

🌟 Selected for report: shw

Also found by: 0xRajeev, gpersoon, pauliax

Labels

bug
duplicate
1 (Low Risk)

Awards

106.1973 USDC - $106.20

External Links

Handle

pauliax

Vulnerability details

Impact

I expect to see nonReentrant on functions with external calls (e.g. moving tokens). Here is a list (it may not be complete) of functions that do not have this modifier: Contract SushiYieldSource functions supplyTokenTo, redeemToken. Contract IdleYieldSource function sponsor. Contract BadgerYieldSource functions supplyTokenTo, redeemToken. Contract ATokenYieldSource function sponsor.

Add nonReentrant modifier to the functions that interact with external actors.

#1 - dmvt

2021-07-31T18:00:57Z

dropping this to a level 1 since no threat is actually defined and the other duplicate issues all agree this is a low risk

#2 - dmvt

2021-07-31T18:01:17Z

duplicate of #119

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax © 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter