Lack of Safe calls

[code423n4]

Handle

0x1f8b

Vulnerability details

Impact

In some cases, they may not make the transfers or approvals.

Proof of Concept

The definition of the ERC-20 standard states that the transfer and transferFrom methods must return a boolean value that determines whether the result was successful or not.
Throughout the audited contracts there are calls to the transfer methods that do not verify this result, leaving the open possibility that the execution is not as expected by the developer.

We recommend that you check the returned value using the require clause or to unify these calls by using the safeTransfer and safeTransferFrom wrappers of OpenZeppelin.

Source reference:

• SavingsAccountUtil.savingsAccountTransfer => L75 transfer, L77 transferFrom
• CreditLine._transferCollateral => L976 transfer
• CreditLine._depositCollateralFromSavingsAccount => L498 transferFrom
• CreditLine._repayFromSavingsAccount => L754 transferFrom
• CreditLine._depositCollateral => L647 approve
• CreditLine._repay => L779 approve
• AaveYield._depositERC20 => L297-298 approve
• AaveYield._withdrawETH => L307 approve
• CompoundYield._depositERC20 => L211-212 approve
• YearnYield._depositERC20 => L210-211 approve

Tools Used

Manual review

Recommended Mitigation Steps

Use safeTransfer, safeApprove and safeTransferFrom

[ritik99]

The transferFrom and transfer implementations are our own (here and here), the issue with approves we're following the recommendations and references provided in #2. Hence we're marking this as disputed and duplicate

[0xean]

dupe of #2