Closed c4-bot-10 closed 7 months ago
0xRobocop marked the issue as duplicate of #158
OpenCoreCH marked the issue as satisfactory
OpenCoreCH changed the severity to 2 (Med Risk)
Hi @OpenCoreCH,
thank you very much for reviewing this contest. I would like to add that the primary issue of this only describes a part of the actual problem. In the protocol, there are 3 functions that are missing slippage control.
The current primary issue only describes the missing slippage parameters for Omnipoool.remove_liquidity() but not the other 2 problems. In the past, the C4 judging on similar situations was to split multiple slippage problems in one protocol into separate issues. Examples of this are:
Vader Protocol:
BadgerDAO
Asymmetry Finance:
In the C4 judging documentation duplicates are defined as follows:
Neither of those is true for the 3 issues described above. They all result out of different parts of the code, and adding slippage protection to one of the functions will not fix the other issues.
Additionally, I want to add that #177 is actually a duplicate of #84 and not of #93
I would argue that they conceptually have the same root cause (missing slippage check) and are resolved by the same solution. Of course, this would affect different lines of code / functions, but if we make this the single criteria for duplicates, it would imply that a codebase with 20 mint
functions could have 20 different slippage issues, which seems not ideal.
Hey @OpenCoreCH,
I understand and agree with you. Nevertheless I would kindly ask you to reconsider why a warden/issue that only found 1/3 problems in the codebase is chosen as the primary issue and also why wardens that only found 1 or 2 out of the 3 issues are awarded fully and not partially.
I think it makes more sense to make me (or another warden) that found all of the issues as the prime issue and also only partially award wardens that did not find all issues.
At first, another issue (#158) that mentions all three functions was chosen as the primary one. While the current only mentions one function, I still think that it provides the most value because it analyzes the issue in detail with a numerical example and directly highlights the potential impact.
Hi @J4X-98 .Since you are suggesting rewarding a warden who found all the issues as the primary report, i would like to point out I did find all the issues: #93, #85, #92. They are all duped with #93 now.
Hey @carrotsmuggler,
did not see that. Congrats on also finding all issues. Consider my comment above void.
Lines of code
https://github.com/code-423n4/2024-02-hydradx/blob/main/HydraDX-node/pallets/omnipool/src/lib.rs#L577
Vulnerability details
Bug Description
HydraDx Protocol's Automated Market Maker (AMM), known as the Omnipool, enables user transactions like adding liquidity. To combat potential front-running of
add_liquidity()
calls, the protocol uses theT::PriceBarrier::ensure_price()
mechanism. This function checks if the current price, which may have been manipulated by front-running, deviates from the oracle's average price by no more than 1%, a limit set in the runtime configuration.However, this safeguard only protects against price manipulations that exceed a 1% deviation, leaving a gap for smaller front-running attacks to occur without detection.
Impact
This vulnerability allows adversaries to execute front-running attacks on
add_liquidity()
transactions that result in less than a 1% loss for the targeted users, thereby exposing them to repeated minor financial losses that are not mitigated by the current protocol defenses.Proof of Concept
The proof of concept demonstrates a scenario where a transaction to
add_liquidity()
is successfully front-run, leading to a slight price change within the 1% tolerance. The protocol fails to prevent the completion of the transaction, showcasing its susceptibility to such front-running strategies.To run the test it needs to be added to the
omnipool/src/tests/remove_liquidity.rs
file.Tools Used
Manual Review
Recommended Mitigation Steps
A practical solution involves allowing users to set their own slippage tolerance level. By adopting a customizable slippage parameter, similar to the approach used in StableSwap's liquidity withdrawal functions, users can better control their acceptable loss margins, potentially avoiding the default up to 1% loss currently in place.
Assessed type
MEV