LaunchEvent's createPair can be cause to always revert

[code423n4]

Handle

UncleGrandpa925

Vulnerability details

Impact

This issue impacts all LaunchEvent, forcing the issuer to write additional contracts to be able to createPair in LaunchEvent else it will always revert.

Issue & Proof of Concept

In LaunchEvent.sol, the function createPair is supposed to be called by anyone at the start of Phase 3 to create the pair & add all the liquidity inside the LaunchEvent to the pool, getting LP back.

On line 411, the action of adding liquidity set the amountAMin & amountBMin to be the equal to wavaxAddress and tokenAllocated respectively. In other words, this forces add all the liquidity inside LaunchEvent to the pool, and will revert if it can't be done.

An attacker can just transfer a non-zero amount of WAVAX (even 1 wei) to the pool preemptively (as the address of the pool is known before Phase 1, long before Phase 3 where createPair is actually called). The attacker then calls sync to force the wavax reserve to be non-zero.

Now that the reserves are non-zero, the router can't simply use the expected path in the Joe Router02's _addLiquidity: if (reserveA == 0 && reserveB == 0) { to dump all the liquidity in, but will have to go with the else part, where it will certainly fail because of the error JoeLibrary: INSUFFICIENT_LIQUIDITY in the quote function.

To prevent this & totally eliminate the chances of front-running, the issuer will have to write an additional contract to call the pool's skim before calling createPair.

Recommended Mitigation Steps

• In the createPair function, check if the pool has existed, if yes, call skim before calling addLiquidity

Note

Proposing this as Medium Risk since it's trivial to exploit and cause troubles for the issurer. Not High risk since the fix is reasonably easy even without modifiying the contract.

[cryptofish7]

Duplicate of #281

[dmvt]

Duplicate of https://github.com/code-423n4/2022-01-trader-joe-findings/issues/197