Byte Masons - Reliquary security record

Linked functions are restricted to execute for valid roles only. Depending on access level, a DEFAULT_ADMIN_ROLE, ADMIN, GUARDIAN, or STRATEGIST role will be required. Any compromise to those accounts may allow a hacker to take advantage of this authority and execute restricted operations in the smart contract.

In the contract `ReaperBaseStrategyv4.sol`, during the authorization process of the UUPS upgrade, the permissions are limited to the following address having the `DEFAULT_ADMIN_ROLE` set: * `msg.sender` address defined during initialization. * an unknown address set as `multisigRole[0]` during initialization. However, no multi-signature validations are found in the codebase that is verified upon a new upgrade request. #### Permissioned functions  #### Upgrade requirements Additionally to this, to run the upgrade process successfully next operations are required to be executed: * The external function `initiateUpgradeCooldown()`must be called to refresh the value of `upgradeProposalTime` to current `block.timestamp`. * The waiting period between the last upgrade and the current upgrade must be bigger than `48h`. This behavior, while adding better reliability and security in a deployed smart contract, limits the ability of the team to face unknown issues and attacks that needs to be patched fast.

The following `burn` function in line 214 of the LendingPoolCollateralManager.sol file could potentially result in reentrancy if the underlying token implementation has a built-in hook akin to ERC677, ERC777, and ERC721. Maliciously implemented hook in the attacker contract could re-enter upon transfer and borrow more by supplying more tokens. The design choice of the underlying chain that deploys the project could also result in an attack if the platform utilizes a different standard for token representation. For example, if a bridge uses an extended ERC677 token for every deposit of ERC20 this will also result in a re-entrancy risk. ```solidity=212 vars.collateralLToken.burn( user, msg.sender, vars.maxCollateralToLiquidate, collateralReserve.liquidityIndex ); ``` ```solidity=222 if (vars.maxCollateralToLiquidate == vars.userCollateralBalance) { userConfig.setUsingAsCollateral(collateralReserve.id, false); emit ReserveUsedAsCollateralDisabled(collateralAsset, user); } ```

The function can be affected by a flashloan attack such that the new stable borrow rate becomes the lowest possible. A malicious actor can first request a flashloan to deposit into the reserve pool so that the reserve’s utilization rate is close to 0, then invoke `swapBorrowRateMode()` to perform the variable-to-borrow rate switch and enjoy the lowest `currentStableBorrowRate`, and finally withdraw to return the flashloan. A similar approach can also be applied to bypass `maxStableLoanPercent` enforcement in `validateBorrow()`.

When transferring standard ERC20 deflationary tokens, the input amount may not be equal to the received amount due to the charged transaction fee. For example, if a user stakes 100 deflationary tokens (with a 10% transaction fee) in a MasterChef, only 90 tokens actually arrived in the contract. However, the user can still withdraw 100 tokens from the contract, which causes the contract to lose 10 tokens in such a transaction. The MasterChef takes the pool token balance(the `lpSupply`) into account when calculating the users' reward. An attacker can repeat the process of deposit and withdraw to lower the token balance(`lpSupply`) in a deflationary token pool and cause the contract to increase the reward amount. Reference: https://thoreum-finance.medium.com/what-exploit-happened-today-for-gocerberus-and-garuda-also-for-lokum-ybear-piggy-caramelswap-3943ee23a39f