If newRatio can differ drastically from the old ibRatio attacks could take place

[code423n4]

Handle

tensors

Vulnerability details

Impact

Consider L91 in Auction.sol. I'm not sure what the logic for updating the ibRatio in this case is. If the newRatio is larger/smaller than the old ibRatio than a user can mint/burn tokens in the basket contract, update the ratio, then burn/mint the received basket tokens for a larger amount of the pool.

Even in the case where the old and new ratio differ by small percent, by using flashloans an attacker can make it worthwhile to carry out such an attack.

Alternatively, an attacker could scan the mempool for an incoming settleAuction() call, and "sandwich" it with a mint transaction in front of it and a burn transaction behind it to get the same effect.

Proof of Concept

https://github.com/code-423n4/2021-09-defiProtocol/blob/52b74824c42acbcd64248f68c40128fe3a82caf6/contracts/contracts/Auction.sol#L91 The above calls update in the basket: https://github.com/code-423n4/2021-09-defiProtocol/blob/52b74824c42acbcd64248f68c40128fe3a82caf6/contracts/contracts/Basket.sol#L216 which is then used in minting and burning.

[frank-beard]

minting/burning is disabled during an auction, so the ibratio cannot be updated in this way

[GalloDaSballo]

Finding is invalid