-
Notifications
You must be signed in to change notification settings - Fork 0
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
Obsidian - By inflating the value of a pool share, a malicious actor can steal a large amount of funds #90
Comments
Good exploit. I am not sure if this is profitable. Attack starts with In step 5 and step 6
Let's consider two iterations: deposit Attacker deposited 3 wei, received 2 wei. Loss = 1 wei, increase in totalAssets = 1 wei deposit Attacker deposited 5 wei, received 3 wei. Loss = 2 wei, increase in totalAssets = 2 wei The addition to totalAssets comes from the loss to attackers. For the totalAsssets:totalShares to become 12e18:1, attacker loses 12e18. The total profit for the attacker is bounded by the |
Escalate This submission (#90) is a duplicate of #597 (along with #582). The 3 submissions demonstrate a way to exponentially inflate the value of shares and steal from the first depositor. The other share inflation submissions (like the one this is currently duplicated with, and also #481) demonstrate low severity impact since they linearly increase the share value, making it infeasible to cause any material loss due to the gas limit. These 3 reports should also be high severity since they can cause large amounts of loss, without any special conditions required. |
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. |
Hi @S3v3ru5, the PoC demonstrates the profitability |
The rounding is intended to make sure it is in favor of the protocol, but the issue around inflation caused by the first depositor seems valid. we intend to fix it by burning shares as done with the SuperPools |
I agree with the sponsor and the escalation. You can also see this comment of mine: #427 (comment) Planning to accept the escalation and duplicate this issue with #597. |
Result: |
Escalations have been resolved successfully! Escalation status:
|
Obsidian
High
By inflating the value of a pool share, a malicious actor can steal a large amount of funds
Summary
By inflating the value of a pool share, a malicious actor can steal a large amount of funds. An attacker can frontrun depositors to steal funds, or frontrun a SuperPool reallocation to steal funds.
Root Cause
Pool.deposit()
rounds DOWN the number of shares minted to the user.Pool.withdraw()
rounds UP the number of shares burned from the user.A classical vault inflation/donation attack involves donating assets to the pool via token transfers. However the classic attack is not possible in this protocol since
totalDepositAssets
are tracked internally via a storage variable.However, through exploiting the rounding directions on
deposit()
andwithdraw()
, a malicious actor can still inflate the value of a single share by a significant amount (1e0 share = 12.15e18 assets). Then, after the next deposit occurs (either a normal deposit, or a SuperPool reallocation), the malicious actor can withdraw their share for profit.Internal pre-conditions
pool.interestFee == 0
External pre-conditions
No response
Attack Path
1e18
into a pool that was newly initialised1e17
assets as collateral, and borrows0.05e18
assetspool.getAssetsOf(fixedRatePool, attacker) - 2
totalAssets = 2, totalShares = 1
2*totalAssets - 1
, and receives 1 share in returntotalAssets
increases whiletotalSupply
remains at 1 due to step 6totalAssets
can be increased to ~ 3^40 (12e18)totalAssets = 12e18
and the depositor deposits20e18
, the new state istotalAssets = 32e18
andtotalShares = 2
totalAssets/2
=16e18
16e18
-12e18
=4e18
, which is a profit of33%
Impact
Loss of funds for the depositor who is frontran by the attacker
The maximum potential profit for the attacker is
50%
, per victim depositor2 * 3^n - 1
wheren
is the number of iterations of step 5-6PoC
Add the following test to
test/integration/POC.t.sol
Proof of Concept
Console output
Mitigation
Burn initial shares in
initializePool
, similar to the burning of initial shares in theSuperPool
Duplicate of #597
The text was updated successfully, but these errors were encountered: