Submitted by Bahurum, also found by dirky_
https://github.com/code-423n4/2022-05-rubicon/blob/8c312a63a91193c6a192a9aab44ff980fbfd7741/contracts/rubiconPools/BathHouse.sol#L153
https://github.com/code-423n4/2022-05-rubicon/blob/8c312a63a91193c6a192a9aab44ff980fbfd7741/contracts/rubiconPools/BathToken.sol#L214
Reentrancy in BathToken.initialize() can be exploited and this allows to create a pool which has a legitimate underlying token (even one for which a pool already exists), and has given full approval of underlying Token to an attacker. While this underlying token will differ from the one returned by  BathHouse.getBathTokenfromAsset for that Pool (since the returned token would be the malicious one which reentered initialize), the LPs could still deposit actual legitimate tokens to the pool since it is deployed from the BathHouse and has the same name as a legit pool, and loose their deposit to the attacker.
Create a new pool calling BathHouse.openBathTokenSpawnAndSignal() and passing as newBathTokenUnderlying the address with the following malicious token:
This reenters BathToken.initialize() and reassigns the bathHouse role to the fake token, which names itself as the legit token. Also the reentrant call reassigns the legit Token to underlyingToken so thet the pool actually contains the legit token, but gives infinite approval for the legit token from the pool to the attacker, who is passed as market in the reentrant call.
Since the fakeToken has the bathHouse role, it can set the market to the actual RubiconMarket after the reentrant call.
Code: BathHouse.openBathTokenSpawnAndSignal, BathToken.initialize
Add onlyBathHouse modifier to initialize function in BathToken to avoid reentrancy from malicious tokens.
bghughes (Rubicon) disputed and commented:
HickupHH3 (judge) commented:
bghughes (Rubicon) confirmed and commented:
