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.
Handle
UncleGrandpa925
Vulnerability details
Impact
This issue impacts all
LaunchEvent
, forcing the issuer to write additional contracts to be able tocreatePair
inLaunchEvent
else it will always revert.Issue & Proof of Concept
In
LaunchEvent.sol
, the functioncreatePair
is supposed to be called by anyone at the start of Phase 3 to create the pair & add all the liquidity inside theLaunchEvent
to the pool, getting LP back.On line 411, the action of adding liquidity set the
amountAMin
&amountBMin
to be the equal towavaxAddress
andtokenAllocated
respectively. In other words, this forces add all the liquidity insideLaunchEvent
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 callssync
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 theelse
part, where it will certainly fail because of the errorJoeLibrary: INSUFFICIENT_LIQUIDITY
in thequote
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 callingcreatePair
.Recommended Mitigation Steps
skim
before callingaddLiquidity
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.