REBALANCER_ROLE can drain funds by rebalancing in a loop in the BorrowingVault
Description
The rebalancer in the borrowing vault receives a fee for providing debtAsset to repay the originating provider and send to the destination provider.
A malicious provider could use this to profit, for example max fee = 10 / 10000 = 1 / 1000 = 0.001 100_000 debt -> 100_100 100_100 deby -> 100200.1 and so on… For this attack, the attacker only needs to pay a flashloan fee once (or have the initial funds available).
Recommendation
The likelihood of this attack is reduced because the rebalancer is a privileged role, but maybe adding a timelock to the rebalancing function would be a good measure so that the chief can disallow a rebalancer if they behave maliciously, before they profit too much from this exploit.
Status
Acknowledged with the following statement: The issue identified is acknowledged by the Fuji team, however, the team will implement the following security measures at the BorrowingVault at a later stage.
The rationale to delay the fixes is that the team does not consider this issue an imminent user risk considering that only the RebalancerManager contract should have the REBALANCER role.
In addition the BorrowingVault bytecode size is near limits and additional logic is not possible until a major refactor. The future measures that will be considered are: 1. Restricting the REBALANCER_ROLE to only contract implementations. This action will reduce the chance of a compromised EOA account.
- Adding a non-reentrant restriction to the rebalance(...) function. This action will restrict the looping optionality that is described in this issue.