Publisher can scam users by changing license fees and using auction to freeze user funds

[code423n4]

Handle

0x0x0x

Vulnerability details

Publisher can call changeLicenseFee to change fees. There is no maximum cap for this parameter. At first glance, because there is a timelock period of 1 day, the users have enough time to react.

But if the publisher can start an auction and bondForRebalance. The publisher can simply not settle the auction and block the basket for 1 day.

So the publisher can make it extremely hard (almost impossible) for users to react to the new license fee. With an extremely high license fee, almost all funds can get stolen by publisher (because of protocol fees also the factory owner gets his share).

Proof of concept

1- Publisher , calls publishNewIndex and proposes new weights.

2- After one day, Publisher calls changeLicenseFee. As license fee a really high amount is set, which does not overflow.

3- After 1-2 blocks, before anyone can react Publisher calls publishNewIndex, bondForRebalance.

4- When TIMELOCK_DURATION of changeLicenseFee ends, the publisher calls it to update the fee.

Recommended mitigation

License fee definitely needs a maximum cap. Furthermore to make it really safe:

First option is to make sure there is a significant difference, between timelock duration for license fee and duration for bondBurn.

The better option is to make sure that an auction cannot be started, when there is a pendingLicenseFee and changeLicenseFee cannot be called during an auction (can also add a resetPendingLicenseFee function to be able to create an auction whenever wanted).

[frank-beard]

duplicate of https://github.com/code-423n4/2021-12-defiprotocol-findings/issues/154

[frank-beard]

also while the publisher could block an auction, minting and burning is disabled during rebalances and thus no fees would be collected