While many Yield protocol functions are authorized to be called from other Yield contracts, the createPool() function in PoolFactory is not authorized and is callable from anyone. This is only supposed to be called from the Wand function addSeries(), which takes a base asset, creates a corresponding fyToken, and then a pool with the two of them. Pool contracts are created deterministically using Create2, but fyTokens are not. If the fyToken were also created deterministically using Create2, or if the Wand created fyToken and the pool in two different transactions, thus making the fyToken address observable to an attacker, the attacker could front-run pool creation to deploy a fake pool and make the real pool creation fail. This is currently not possible.
However, anyone can create a fake pool with the real base asset address but a fake fyToken. If the threat model is extended to integrating contracts/front-ends that may assume all pools created (as indicated by emitted events) by createPool to be authentic ones (like the one created from the Wand), they may end up interacting or allow interactions with a fake pool which may lead to users losing funds.
Alice creates a front-end that observes PoolCreated events emitted by createPool to automatically list them as Yield pools. An attacker creates a fake pool with Dai as base asset and a corresponding fake/malicious fyToken contract. Users of Alices front-end end up interacting with the fake Yield pool and losing funds.
Recommend considering adding auth to the createPool function and permissioning only Wand to access this function for creating pools.
albertocuestacanada (Yield) disputed:
