Phoenix-Protocol-Group / phoenix-contracts

Source code of the smart contracts of the Phoenix DeFi hub DEX protocol
GNU General Public License v3.0
10 stars 7 forks source link

[V-PHX-VUL-005] Deployment of pools can be front-runned #179

Closed gangov closed 9 months ago

gangov commented 9 months ago

The pool contract diverges from a permission-less model as it incorporates a privileged account, commonly referred to as the admin. This admin possesses the authority to modify crucial configurations within the pool contract. Notably, the admin is empowered to upgrade the contract's WebAssembly (wasm) through the dedicated upgrade function. It's important to note that the identifier (address) of the pool contract relies on the deployer account (linked to the factory contract) and the addresses of the associated token pair, namely tokenA and tokenB. Consequently, the system is designed to allow only one pool to exist for a given pair of tokens. However, a noteworthy concern arises as any user has the capability to deploy a pool for any token pair, irrespective of ownership or legitimate authorization.

Impact

The permission-less creation of pools through the factory contract introduces a potential vulnerability. Since each pair of tokens can only have one pool, a malicious user could exploit this by creating pools for specific tokens, like tokenB and USDC. This action allows the malicious actor to hinder the genuine creators of tokenB from utilizing the system.

Recommendation

Only whitelisted accounts should be able to use the factory contract to create pools.

gangov commented 9 months ago

I'll create a new field in Config that will hold all whitelisted accounts in a vec, would we need a new method to update it? Otherwise, we will have to re-deploy the factory every time we decide that a new whitelisted account is needed.