No re-entrancy checking in BunniSupply and AuraBalancerSupply.
Summary
In BunniSupply, it calculates Protocol Owned Liquidity by querying reserves from UniswapV3 pool, but it's not checking if current state is re-entered.
In AuraBalancerSupply, it calculates Protocol Owned Liquidity by querying reserves from Balancer and Aura pools, but it's not checking if current state is re-entered.
Vulnerability Detail
In BunniSupply, it calculates the OHM amount of Protocol Owned Liquidity by querying BunniLens and which calculates reserves using associated Uniswap V3 pool.
Same for AuraBalancerSupply, it queries reserves from Balancer and Aura pools.
However, it doesn't check if current state is re-entered, e.g. in callback of UniswapV3's swap function.
This vulnerability leads to OHM supply manipulation which can be abused by an attacker.
For example, an attacker can increase floatingSupply and decrease polSupply by calculating these amounts in callback of Uniswap's swap function.
FYI, checking deviation in BunniSupply does not detect this vulnerability because slot0 is updated before callback is called.
Impact
Reentrancy vulnerability leads to token supply manipulation, which can be abused by an attacker.
In BunniSupply, it has to check slot0.unlocked for re-entrancy.
In AuraBalancerSupply, it has to check re-entrancy using VaultReentrancyLib.ensureNotInVaultContext(balVault);.
Invalid, insufficient proof that reentrancy can occur.
In fact, reentrancy protections are performed in the BunniLens contract as indicated here and performed here for BunniSupply.getProtocolOwnedLiquidityReserves.
For AuraBalancer.getProtocolOwnedLiquidityOhm() reentrancy is performed here
nevillehuang
commented
6 months ago
KupiaSec
medium
No re-entrancy checking in
BunniSupplyandAuraBalancerSupply.Summary
In
BunniSupply, it calculates Protocol Owned Liquidity by querying reserves from UniswapV3 pool, but it's not checking if current state is re-entered. InAuraBalancerSupply, it calculates Protocol Owned Liquidity by querying reserves from Balancer and Aura pools, but it's not checking if current state is re-entered.Vulnerability Detail
In
BunniSupply, it calculates the OHM amount of Protocol Owned Liquidity by queryingBunniLensand which calculates reserves using associated Uniswap V3 pool. Same forAuraBalancerSupply, it queries reserves from Balancer and Aura pools.However, it doesn't check if current state is re-entered, e.g. in callback of UniswapV3's swap function. This vulnerability leads to OHM supply manipulation which can be abused by an attacker. For example, an attacker can increase
floatingSupplyand decreasepolSupplyby calculating these amounts in callback of Uniswap's swap function.FYI, checking deviation in
BunniSupplydoes not detect this vulnerability becauseslot0is updated before callback is called.Impact
Reentrancy vulnerability leads to token supply manipulation, which can be abused by an attacker.
Code Snippet
BunniSupply https://github.com/sherlock-audit/2023-11-olympus/blob/9c8df76dc9820b4c6605d2e1e6d87dcfa9e50070/bophades/src/modules/SPPLY/submodules/BunniSupply.sol#L171-L195 https://github.com/sherlock-audit/2023-11-olympus/blob/9c8df76dc9820b4c6605d2e1e6d87dcfa9e50070/bophades/src/modules/SPPLY/submodules/BunniSupply.sol#L212-L260
AuraBalancerSupply https://github.com/sherlock-audit/2023-11-olympus/blob/9c8df76dc9820b4c6605d2e1e6d87dcfa9e50070/bophades/src/modules/SPPLY/submodules/AuraBalancerSupply.sol#L332-L370
Tool used
Manual Review
Recommendation
In
BunniSupply, it has to checkslot0.unlockedfor re-entrancy. InAuraBalancerSupply, it has to check re-entrancy usingVaultReentrancyLib.ensureNotInVaultContext(balVault);.