Open hats-bug-reporter[bot] opened 9 months ago
Thank you for the submission. From the manual review of it I can confirm the finding (method uses cached value of the reserves rather than the updated ones). I can't compile, or run your test case though. I'll fix it myself but there are multiple problems with (compilation and runtime) so please, make sure you're including the complete PoC next time.
Hi @deuszx I have also added these lines to the utils.rs
pub const CHARLIE: drink::AccountId32 = AccountId32::new([3u8; 32]);
pub fn charlie() -> ink_primitives::AccountId {
AsRef::<[u8; 32]>::as_ref(&CHARLIE).clone().into()
}
and changed the amount minted in psp22 to 2_000_000_000 * 10u128.pow(18)
. Also, it's using the newly provided drink tests.
Thank you for participation. After carefully reviewing the submission we've decided to accept it as VALID and the suggested severity level HIGH.
We hope to see you in the future ink! codebase audits.
Github username: @coreggon11 Twitter username: krikoeth Submission hash (on-chain): 0xfa2f634e33a1c66390a57717bef271960460209ff9ecd5aab11e7bb43ebce999 Severity: high
Description: Description\ The factory contract holds the information about protocol fee benefeciary. If this field is set to
Some(account)
, then the protocol should accrue 5 basis points fee from the trades, resulting in 16% of the pair fees to be sent to the protocol (fee_to
).However, there is a bug in the current implementation, which will result in not only a portion of the pair fees being sent to the fee beneficiary but also a significant portion of the liquidity added or removed.
Attack Scenario\ Bob provides liquidity for the first time. At the end of the call,
k_last
will be updated, but it will be set toSome(0)
since it multiplies the members of a local tuple initialized here, which in the beginning is equal to(0, 0)
.Right after that, Bob will provide the same amount of liquidity (for the sake of this example, it can be any amount of liquidity). During
mint_fee
, the control flow goes to this condition, and since sqrt ofk_last
is 0, this condition will betrue
as well. This will result in minting 16% more liquidity, with the overflowing liquidity being sent to the protocol fee collector, which will result in Bob being able to withdraw back significantly less than provided.Proof of Concept
Recommended mitigation steps:
Consider setting the k_last during
mint
andburn
to the newly updated value.Affected places: mint, burn