-
Notifications
You must be signed in to change notification settings - Fork 3
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
fibonacci - JalaPair potential permanent DoS due to overflow #186
Comments
Request poc Would like the watson/watsons to present a scenario where a reasonable overflow can be achieved, because based on my discussion with LSW this is likely not reasonable considering frequency of liquidity addition and ratio of reserves required
|
PoC requested from @0xf1b0 Requests remaining: 10 |
Even if we do not take reserves into account, the timestamp is converted into a 32-bit value.
When the timestamp gets >4294967296 (in 82 years), the |
The linked issue presented a way to DoS functionality. Is this also the case here? Or are funds locked here as well? |
@Czar102 Agree, if long enough, all core functionalities |
Escalate
|
You've created a valid escalation! To remove the escalation from consideration: Delete your comment. You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final. |
I will invite any watsons to prove if accumulated actions (swap, burn and mint) can cause overflow in price variables (whether maliciously or accidentally) |
Timestamp overflow is less of a concern here, cumulative value is.
It's a clear mistake on the devs, which has an easy fix to wrap with unchecked block. Not sure why they won't fix it. |
@giraffe0x hey, please check the initial message by @nevillehuang on why cumulatives cannot actually overflow. |
@deadrosesxyz, Could a malicious user(s) (despite requiring alot of funds) be able to brick the pool permanently by constantly performing actions (burn, swap, mint) and incrementing price variables? |
@nevillehuang No, constantly performing actions will not help for an overflow to occur in any way (as the cumulative increases based on seconds passed). Even in the most extreme scenario where one of the reserves has max value and the other one has simply 1 wei, it would take 132 years for an overflow to occur. Quoting my comments from earlier:
|
This would depend on how @Czar102 interprets the following rule given he agreed initially that this should remain as a valid medium severity as seen here
|
It really doesn't matter if it was left out from the copying of original univ2 contracts. The intent is for it to overflow but it won't in this case. Also if the pairs are tokens with decimals greater than 18, the DOS will occur sooner. |
@deadrosesxyz It will actually take less than 132 years because the pair could have a token1 max reserve of uint112 and token0 reserve of 1 wei on the first block. This means that timeElapsed will be the block.timestamp of the first block (something like 1710940084 now). This means that 52.25 years of those 132 years have already passed. It is still a big number, however, it is easy to fix and a clear mistake on the devs. |
I maintain my judgment from preliminary judging – I think it should be Medium especially because of the "overflow is desired" comment, which means that sponsors care about the behavior in far future. Without these comments, the judgment on this issue would be disputable. Planning to reject the escalation and leave the issue as is. |
Result: |
Escalations have been resolved successfully! Escalation status:
|
fibonacci
medium
JalaPair potential permanent DoS due to overflow
Summary
In the
JalaPair::_update
function, overflow is intentionally desired in the calculations fortimeElapsed
andpriceCumulative
. This is forked from the UniswapV2 source code, and it’s meant and known to overflow. UniswapV2 was developed using Solidity 0.6.6, where arithmetic operations overflow and underflow by default. However, Jala utilizes Solidity >=0.8.0, where such operations will automatically revert.Vulnerability Detail
Impact
This issue could potentially lead to permanent denial of service for a pool. All the core functionalities such as
mint
,burn
, orswap
would be broken. Consequently, all funds would be locked within the contract.I think issue with High impact and a Low probability (merely due to the extended timeframe for the event's occurrence, it's important to note that this event will occur with 100% probability if the protocol exists at that time), should be considered at least as Medium.
References
There are cases where the same issue is considered High.
https://solodit.xyz/issues/h-02-uniswapv2priceoraclesol-currentcumulativeprices-will-revert-when-pricecumulative-addition-overflow-code4rena-phuture-finance-phuture-finance-contest-git
https://solodit.xyz/issues/m-02-twavsol_gettwav-will-revert-when-timestamp-4294967296-code4rena-nibbl-nibbl-contest-git
https://solodit.xyz/issues/trst-m-3-basev1pair-could-break-because-of-overflow-trust-security-none-satinexchange-markdown_
Code Snippet
https://github.com/sherlock-audit/2024-02-jala-swap/blob/main/jalaswap-dex-contract/contracts/JalaPair.sol#L97-L102
Tool used
Manual Review
Recommendation
Use the
unchecked
block to ensure everything overflows as expectedThe text was updated successfully, but these errors were encountered: