Adversary can sandwich oracle updates to exploit vault
BLVaultLido added a mechanism to siphon off all wstETH obtained from mismatched pool and oracle prices. This was implemented to fix the problem that the vault could be manipulated to the attackers gain. This mitigation however does not fully address the issue and the same issue is still exploitable by sandwiching oracle update.\\nBLVaultLido.sol#L232-L240\\n```\\n    uint256 wstethOhmPrice = manager.getTknOhmPrice();\\n    uint256 expectedWstethAmountOut = (ohmAmountOut * wstethOhmPrice) / _OHM_DECIMALS;\\n\\n    // Take any arbs relative to the oracle price for the Treasury and return the rest to the owner\\n    uint256 wstethToReturn = wstethAmountOut > expectedWstethAmountOut\\n        ? expectedWstethAmountOut\\n        : wstethAmountOut;\\n    if (wstethAmountOut > wstethToReturn)\\n        wsteth.safeTransfer(TRSRY(), wstethAmountOut - wstethToReturn);\\n```\\n\\nIn the above lines we can see that the current oracle price is used to calculate the expected amount of wstETH to return to the user. In theory this should prevent the attack but an attacker can side step this sandwiching the oracle update.\\nExample:\\nThe POC is very similar to before except now it's composed of two transactions sandwiching the oracle update. Chainlink oracles have a tolerance threshold of 0.5% before updating so we will use that as our example value. The current price is assumed to be 0.995 wstETH/OHM. The oracle price (which is about to be updated) is currently 1:1\\n```\\nTransaction 1:\\n\\nBalances before attack (0.995:1)\\nLiquidity: 79.8 OHM 80.2 wstETH\\nAdversary: 20 wstETH\\n\\nSwap OHM so that pool price matches pre-update oracle price:\\nLiquidity: 80 OHM 80 wstETH\\nAdversary: -0.2 OHM 20.2 wstETH\\n\\nBalances after adversary has deposited to the pool:\\nLiquidity: 100 OHM 100 wstETH\\nAdversary: -0.2 OHM 0.2 wstETH\\n\\nBalances after adversary sells wstETH for OHM (0.5% movement in price):\\nLiquidity: 99.748 OHM 100.252 wstETH\\nAdversary: 0.052 OHM -0.052 wstETH\\n\\nSandwiched Oracle Update:\\n\\nOracle updates price of wstETH to 0.995 OHM. Since the attacker already sold wstETH to balance \\nthe pool to the post-update price they will be able to withdraw the full amount of wstETH.\\n\\nTransaction 2:\\n\\nBalances after adversary removes their liquidity:\\nLiquidity: 79.798 OHM 80.202 wstETH\\nAdversary: 0.052 OHM 19.998 wstETH\\n\\nBalances after selling profited OHM:\\nLiquidity: 79.849 OHM 80.152 wstETH\\nAdversary: 20.05 wstETH\\n```\\n\\nAs shown above it's still profitable to exploit the vault by sandwiching the oracle updates. With each oracle update the pool can be repeatedly attacked causing large losses.
To prevent this I would recommend locking the user into the vault for some minimum amount of time (i.e. 24 hours)
Vault will be attacked repeatedly for large losses
```\\n    uint256 wstethOhmPrice = manager.getTknOhmPrice();\\n    uint256 expectedWstethAmountOut = (ohmAmountOut * wstethOhmPrice) / _OHM_DECIMALS;\\n\\n    // Take any arbs relative to the oracle price for the Treasury and return the rest to the owner\\n    uint256 wstethToReturn = wstethAmountOut > expectedWstethAmountOut\\n        ? expectedWstethAmountOut\\n        : wstethAmountOut;\\n    if (wstethAmountOut > wstethToReturn)\\n        wsteth.safeTransfer(TRSRY(), wstethAmountOut - wstethToReturn);\\n```\\n