-
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
Ethereum address collision can be used to steal funds via mint and swap callbacks #128
Labels
2 (Med Risk)
Assets not at direct risk, but function/availability of the protocol could be impacted or leak value
bug
Something isn't working
duplicate-247
satisfactory
satisfies C4 submission criteria; eligible for awards
sponsor confirmed
Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")
Comments
c4-bot-3
added
2 (Med Risk)
Assets not at direct risk, but function/availability of the protocol could be impacted or leak value
bug
Something isn't working
labels
Dec 3, 2023
Picodes marked the issue as primary issue |
c4-judge
added
the
primary issue
Highest quality submission among a set of duplicates
label
Dec 14, 2023
This was referenced Dec 14, 2023
c4-sponsor
added
the
sponsor confirmed
Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")
label
Dec 15, 2023
dyedm1 (sponsor) confirmed |
That's fair as a Medium. Uniswap's own contracts all use the computation method, but I'm all for paranoid security. |
Picodes marked the issue as satisfactory |
c4-judge
added
the
satisfactory
satisfies C4 submission criteria; eligible for awards
label
Dec 23, 2023
Picodes marked the issue as selected for report |
c4-judge
added
the
selected for report
This submission will be included/highlighted in the audit report
label
Dec 23, 2023
c4-judge
added
duplicate-247
and removed
primary issue
Highest quality submission among a set of duplicates
selected for report
This submission will be included/highlighted in the audit report
labels
Dec 26, 2023
Picodes marked issue #247 as primary and marked this issue as a duplicate of 247 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
2 (Med Risk)
Assets not at direct risk, but function/availability of the protocol could be impacted or leak value
bug
Something isn't working
duplicate-247
satisfactory
satisfies C4 submission criteria; eligible for awards
sponsor confirmed
Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")
Lines of code
https://github.com/code-423n4/2023-11-panoptic/blob/main/contracts/SemiFungiblePositionManager.sol#L415
https://github.com/code-423n4/2023-11-panoptic/blob/main/contracts/SemiFungiblePositionManager.sol#L449
Vulnerability details
Impact
An attacker could generate an address that passes the CallbackValidation.verifyCallback check in Uniswap’s routers swap callback, but isn't actually a Uniswap pool.
uniswapV3MintCallback
anduniswapV3SwapCallback
are external functions. Anyone can call them and ask the position manager to transfer funds from a user's address directly to themsg.sender
address. The only access control check this call:CallbackLib.validateCallback(msg.sender, address(FACTORY), decoded.poolFeatures);
That check can be bypassed through using a maliciously generated
msg.sender
address, and used to steal all balances in users' wallets approved for the position manager.I'm submitting this as a medium, because the attack is unlikely to be profitable (at least in the near-term future) due to the computational cost required.
Proof of Concept
An attacker can mine for two sets of addresses, using powerful hardware:
S1: Addresses that pass the CallbackLib.validateCallback check, but don't correspond to a real deployed Uniswap pool.
S2: EOA for which the attacker has the private key, or smart contract addresses that have the attack code and under control of the attacker (e.g. created using the create2 call).
The set S1 is mined by selecting a valuable real token (such as USDC as token0/token1), creating different random values for the paired token (for token1/token0) address, and storing the resulting pool address values in an efficient data structure, such as the Bloom filter.
If an address is found that belongs both to S1 and S2, the attacker can steal all the approved real token balances from a user's wallet by calling the callback functions, with
amount0Owed
andamount1Owed
set by the attacker to match the user's approved balances.Feasibility of the attack
Ethereum address size is 160 bits. Due to the birthday paradox the complexity of the attack on the order of 2^81 (computed as 2*2^(160/2), as two sets of addresses are mined). Already today, this complexity is not out of the scope of large or state-level actors, and will get much more feasible in the future.
Similar issue was discovered and at length described in an audit for the Kyber Swap protocol:
https://github.com/sherlock-audit/2023-07-kyber-swap-judging#issue-m-2-routersol-is-vulnerable-to-address-collission
It was considered a valid issue and paid by the sponsor.
Additional information to consider:
Vitalik Buterin in November 2021 claims that:
“even without address space extension, collisions today take 2^80 time to compute, and that length of time is already within range of nation-state-level actors willing to spend huge amounts of resources. For reference, the Bitcoin network performs 2^80 SHA256 hashes once every two hours.”
https://ethresear.ch/t/what-would-break-if-we-lose-address-collision-resistance/11356
Mysten Labs have recently (October 2023) estimated the cost of a collision attack. They claim that “it's not a surprise that today, a 2^80 attack would cost a few million dollars”.
https://mystenlabs.com/blog/ambush-attacks-on-160bit-objectids-addresses
Recommended Mitigation Steps
Change the
validateCallback
to callfactory.getPool
to check thatmsg.sender
is a Uniswap pool deployed by this factory.Assessed type
Access Control
The text was updated successfully, but these errors were encountered: