-
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
Atharv - Dilution of Donations in Tranche #121
Comments
1 comment(s) were left on this issue during the judging contest. takarez commented:
|
Low severity, A combination of Front and Back running not possible on Base, Optimism and Arbitrum due to private sequencers. Other chains were not explicitly mentioned, or at least all the issues and the duplicates do not present a possible chain where a sandwich attack is possible. |
Escalate I'm escalating this on behalf of @pa-sh0k because I believe his claims should be considered via a proper escalation. This is what he states: The loss of funds can be caused not only if the attacker executes an atomic sandwich attack, but also if they do the following steps:
Hence, the reason for invalidation is incorrect. Also, the sponsor has acknowledged the issue in discord channel. By Sherlock’s rules, this issue is a medium, it suits the following criteria: “Causes a loss of funds but requires certain external conditions or specific states, or a loss is highly constrained. The losses must exceed small, finite amount of funds, and any amount relevant based on the precision or significance of the loss”. |
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. |
If such a backrun would happen, the admin would just not donate via The auction proceeds would in this case donated via different means (it is already the unhappy flow of an unhappy flow where things have to be handled manually). So the attacker has the risk that they have to provide liquidty in the Tranche for un unknown amount of time, without any certainty of profits at all. |
Detecting the backrun and getting the funds back to the depositors via different means is indeed a solution to the problem. The issue still exists and it can be prevented using the described method only if it was known beforehand, but it was not stated in the known issues or anywhere else. I have said this in the discord channel, but since the conversation was moved here, I will add a quote so anyone can understand the context:
Also, wanted to state that my issue, #128 , is a duplicate of this one and everything said in this discussion is applicable to it and vice versa. |
I want to state again that Normally if the protocol functions as expected, auctions terminate automatically. We however foresaw a flow that if for some reason an auction would not end (this already means things did not work out as expected), a trusted user (set by the Creditor) can manually liquidate the assets. After the assets are liquidated he can choose if and how to distribute the assets to potentially impacted users. There are no guaranteed losses for LPs, and attackers have no guaranteed way to make profits, but have to put significant amounts of capital at stake. Note on the recommendations:
Snapshots are not mutually exclusive from
This creates new issues and risks since the the locking mechanisms of Tranches are already complex. |
Before this issue was submitted, escalated and this discussion was started, it was not stated anywhere, that backrunning activity will be monitored and if something malicious is noticed, other ways of liquidation settling will be used. If you have known about such attack vector and already had other ways of handling it, it should have been stated in the known issues. |
It is a trusted manual flow executed by a permissioned role! |
Agree with sponsor comments here, this issue should remain low severity. |
The fact that it is executed by a permissioned role is already assumed in the issue. The issue is that when trusted manual flow is executed by a permissioned role using What is stated in the code (LendingPool.sol#L346-L347) about
From this comment it cannot be concluded that backrunning will be monitored and if something malicious is noticed, other ways of liquidation settling will be used. The fact that this flow is executed by a permissioned role does not make it invincible. What was stated previously:
Obviously, this issue can't be prevented it is not known about by the admin. Since it was submitted, which is my job as a Watson, now the admins know about it and can prevent the loss of funds. Addressing the Sherlock's criteria: “Causes a loss of funds but requires certain external conditions or specific states, or a loss is highly constrained. The losses must exceed small, finite amount of funds, and any amount relevant based on the precision or significance of the loss”. This issue requires certain external conditions and causes loss of funds if these conditions are met. Regarding the following words of the sponsor:
Attacker is guaranteed to make profits if the conditions are met. Also, probability of depositing funds into the protocol as a liquidity provider for a short period of time, which the attacker would have to do, has near-to-zero risk of losing money. They would probably even make money by providing liquidity. |
As we say in the comment: It is supposed to serve as a way to compensate the jrTranche after an auction didn't get sold and was manually liquidated after cutoffTime. not It is supposed to serve as the way to compensate the jrTranche after an auction didn't get sold and was manually liquidated after cutoffTime. Addressing the Sherlock's criteria: We even state that this flow is not enforced by the smart contracts: |
"Not enforced by the smart contracts" is equal to "it is manual", which is already assumed in the issue. The issue is invalid if The argument that if admin wants to use If other way of refunding is chosen for some other reasons, the attacker can simply withdraw their funds at no loss. |
This comment was marked as spam.
This comment was marked as spam.
Let's not use chatGPT when discussing the findings. |
I would like to add that even if there is no attacker, this will harm other users' profits. As long as a new user deposits assets into jrTranche after |
It seems that the donation was to be to Tranches, not to Tranches' holders at the time of the auction/auction failure. This itself is a logical issue that should be recognized as the core issue here. I think most doubts regarding the validity of this issue come from the fact that modifying the planned usage of the functionality solves this issue. I don't think this means that an issue is invalid. If I am mistaken and there is other clear evidence that the donation was to be done to holders at the time the auctioned assets were subtracted from a tranche's balance, I will agree with invalidation. Right now, the sponsor's arguments seem to be that this the comments were suggesting a route for next steps, and these steps could be different. Without mentioning the mint monitoring checks, this seems to be equivalent to an approach that "in a manual action, we would notice this issue", while assuming that the issue will be found anyway doesn't invalidate its existence. |
@Czar102 This issue is definitely possible, however, |
@nevillehuang why "not a core functionality" is used as an argument for issue's invalidity? It is definitely in scope and is a part of the protocol |
The function is never called from a function within the protocol. If you read my comments above I am not denying it is an issue, I stated that since there is no guarantee on profit and it can even be avoided there is ever profit for an attacker, I consider it a low issue. |
Is there an expectation of a donation of nonzero proceeds in the unhappy flow? Or are positive proceeds not expected? @Thomas-Smets |
Also dilutes the donations for users. |
It is clearly mentioned here that it is used to compensate the tranche after an auction didn't get sold (unhappy flow) |
My point of view: it is a low issue We are talking about an emergency situation where the protocol already didn't function as expected and that has to be resolved 100% manually. And in no way is
Not sure I fully understand the question, @Atharv181, It is clearly mentioned here that it is used to compensate the tranche after an auction didn't get sold (unhappy flow) We say very clear: It is A way. We do not say it is the way. |
The situation of unhappy flow hasn't been taken out of scope (despite it being perceived as extremely improbable), and it has been explicitly mentioned that the Since this approach is exploitable, I'm planning to consider it a valid Medium severity issue. |
Result: |
Escalations have been resolved successfully! Escalation status:
|
Atharv
medium
Dilution of Donations in Tranche
Summary
In this attack, the attacker takes advantage of the non-atomic nature of the donation and the share valuation process. By strategically placing deposit and withdrawal transactions around the donation transaction, the attacker can temporarily inflate their share of the pool to capture a large portion of the donated funds, which they then quickly exit with, leaving the pool with their original investment plus extra value extracted from the donation.
Vulnerability Detail
Though there is no reasonable flow where users will just 'donate' assets to others, Risk Manager may needs to call
donateToTranche
to compensate the jrTranche after an auction didn't get sold and was manually liquidated after cutoff time or in case of bad debt.donateToTranche
function of a lending pool smart contract, allows for a sandwich attack that can be exploited by a malicious actor to dilute the impact of donations made to a specific tranche. This attack involves front-running a detected donation transaction with a large deposit and following it up with an immediate withdrawal after the donation is processed.The lending pool contract in question allows liquidity providers (LPs) to deposit funds into tranches, which represent slices of the pool's capital with varying risk profiles. The
donateToTranche
function permits external parties to donate assets to a tranche, thereby increasing the value of the tranche's shares and benefiting all LPs proportionally. Transactions can be observed by one of the LP's before they are mined. An attacker can exploit this by identifying a pending donation transaction and executing a sandwich attack. This attack results in the dilution of the donation's intended effect, as the attacker's actions siphon off a portion of the donated funds.Impact
Dilution of Donation: The intended impact of the donation on the original LPs is diluted as the attacker siphons off a portion of the donated funds.
Steps to Reproduce Issue
Front-Running: The attacker deposits a significant amount of assets into the target tranche before the donation transaction is confirmed, temporarily increasing their share of the tranche.
Donation Processing: The original donation transaction is processed, increasing the value of the tranche's shares, including those recently acquired by the attacker.
Back-Running: The attacker immediately withdraws their total balance from the tranche, which now includes a portion of the donated assets, effectively extracting value from the donation meant for the original LPs.
Code Snippet
Code Snippet
Coded PoC
https://github.com/Atharv181/Arcadia-POC
Tool used
Manual Review, Foundry
Recommendation
The text was updated successfully, but these errors were encountered: