Reentrancy Vulnerability in Sentiment.xyz

Balancer had a read only reentrancy vulnerability. This happens when a read only function, outside of the protocol, calling back into the function within a weird state. The reentrancy checks don't work, since it's normally not put onto view functions. The vulnerability comes from the function _joinOrExit. It invokes the function _callPoolBalanceChange before calling _setMinimalSwapInfoPoolBalances. This is important because _setMinimalSwapInfoPoolBalances updates the token balances for balancer. The interesting part is that the protocol will always send back unused Ether to the user part way through execution via sendValue. The transferring of the ETH is in the middle of the execution of _callPoolBalanceChange but before _setMinimalSwapInfoPoolBalances. This means that the Balancer pool tokens have been minted but the vault has NOT been updated at this stage. This puts the contract into a funky state. So, reentrancy to steal all of the money with consecutive calls, right? Well, not so fast. These functions have reentrancy modifiers on them in order to prevent this. The modifiers are only placed on external functions that modify the state typically. This still means a read only reentrancy is possible though. If an attacker sets up a fallback function where the extra ETH gets sent back to, they could make read only calls to the contract using this exploit. Further analysis of this vulnerability can be found on the Balancer Forums. What even uses these read only calls though? Pricing oracles! In the case of Sentiment.xyz, they were using Balancer as an oracle for how much each token costs. The attacker performed the following steps to exploit this: Take out a flash loan and put assets into Sentiment.xyz as collateral. Manipulate the Balancer pool. Setup a reentrant contract to call the exitPool function. Call Sentiment.xyz with the manipulated pool prices to obtain collateral back at an extremely high cost. Profit. I'm a little confused on how Sentiment.xyz got exploited on this, since this is an issue with Balancer and Balancer patched the problems. My hypothesis is that Sentiment.xyz was using an older version of the pool that was vulnerable or was not using the information from the contract properly. Overall, super interesting vulnerability!