-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interactions with AMMs do not use deadlines for operations #429
Comments
dmvt marked the issue as primary issue |
dmvt marked the issue as selected for report |
From a practical point of view, this would require the collusion of a large amount of miners which is extraordinarily unlikely. Each miner is incentivized to maximize TX fees in a block, rather than plan a theoretical liquidation some long time in the future. |
@trust1995 I didn't even participate in the contest, so I don't have any incentives. However, I see it very unfair to judge it as "suggestion". The described report logically fully satisfies the description of the Medium severity bug. From the medium severity bug description.
Doesn't the report show hypothetical attack paths with external requirements? |
I don't see this attack as different from general miner collusion, i.e. when deadline parameters are passed by user "properly". It is a property of Eth style blockchains. |
To invalidate this or mark it as a suggestion is the same as asserting that the deadline timestamp is an unnecessary part of an AMM design. The recent decision linked in the issue states exactly the opposite. I agree that:
I also agree with the medium risk rating given to the issue in the previous contest. Those these two issues do diverge slightly, the risk and impact are the same. |
Contrarily, to mark the decision as M means issue has demonstrated a core dis-functioning, or a theoretical risk of funds with stated hypotheticals. Neither is evident from the issue.
There is no actual risk of funds here. The NToken holding counts as collateral. I agree deadline is a useful tool for AMMs. I disagree that the way in which it is used here equates to a M-level impact. |
Your opinion is noted, but in the absence of further information, this issue is valid and will remain medium risk. |
Lines of code
https://github.com/code-423n4/2022-11-paraspace/blob/c6820a279c64a299a783955749fdc977de8f0449/paraspace-core/contracts/protocol/tokenization/NTokenUniswapV3.sol#L51-L76
Vulnerability details
Impact
From a judge's contest in a previous contest:
Most of the functions that interact with AMM pools do not have a deadline parameter, but specifically the one shown below is passing
block.timestamp
to a pool, which means that whenever the miner decides to include the txn in a block, it will be valid at that time, sinceblock.timestamp
will be the current timestamp.Proof of Concept
https://github.com/code-423n4/2022-11-paraspace/blob/c6820a279c64a299a783955749fdc977de8f0449/paraspace-core/contracts/protocol/tokenization/NTokenUniswapV3.sol#L51-L76
A malicious miner can hold the transaction, which may be being done in order to free up capital to ensure that there are funds available to do operations to prevent a liquidation. It is highly likely that a liquidation is more profitable for a miner to mine, with its associated follow-on transactions, than to allow the decrease of liquidity. A miner can also just hold it until maximum slippage is incurred, as the judge stated.
Tools Used
Code inspection
Recommended Mitigation Steps
Add deadline arguments to all functions that interact with AMMs, and pass it along to AMM calls
The text was updated successfully, but these errors were encountered: