1. Curve shares is removed 2. ETH is sent back, STETH is not yet sent So the imbalance in ETH - STETH is calculated as "profit". Hence virtual price is higher
if the developers reverse the sequence of loop such that the 0th element ie. ETH amount comes last in the execution of the iteration, will this vulnerability be resolved? It should look something like this: for i in xrange(N_COINS, 0, -1): value: uint256 = amounts[i] * _amount / total_supply assert value >= _min_amounts[i], "Withdrawal resulted in fewer coins than expected" amounts[i] = value if i == 0: raw_call(msg.sender, b"", value=value) else: assert ERC20(self.coins[1]).transfer(msg.sender, value) log RemoveLiquidity(msg.sender, amounts, empty(uint256[N_COINS]), total_supply - _amount) return amounts
Great vid! Love ur take on security matters. Would have loved a “how to avoid part”, but this one is fairly simple to prevent. Sry to persist, but could you make a video on bit-shifting in the v2 uniswap contract. With this im referring to the math behind the FixedPoint.uq122x122. Since your bit conversion video, i was left intrigued in how a bit shift would look with the dex values. Seeing as you can apply some logic to all bits in a 122 range for some purpose. Love your videos! Cheers
Curve should have updated all financial state prior to sending the funds out. The reason for this being possible is the callback function in the middle of a state change. tldr; Don't be in an in-between state for important variables when external contract calls are made. Otherwise, the functions in use by other contracts could be manipulated via Read Only reentrancy.
0:00 - Intro
0:55 - Initialize Foundry
1:16 - Code Hack contract
4:01 - Curve remove_liquidity function
8:31 - Write test
9:57 - Execute test
11:15 - Code Target contract
14:44 - Update Hack contract
17:21 - Update test
18:24 - Execute test again
19:11 - Summary
Code
github.com/stakewithus/defi-by-example/tree/main/read-only-reentrancy
Curve STETH contract
github.com/curvefi/curve-contract/blob/master/contracts/pools/steth/StableSwapSTETH.vy
Take a course
www.smartcontract.engineer/
A suggestion. You need to author a book on Solidity cause you have vast knowledge
I support the suggestion. Great mind and a helpful spirit. I'd buy your book.
This was very enlightening. Been watching for a while and this is the best.
New playlist started. Was waiting for this ....
Just one question: why virtual price should be higher during remove_liquidity function execution?
1. Curve shares is removed
2. ETH is sent back, STETH is not yet sent
So the imbalance in ETH - STETH is calculated as "profit". Hence virtual price is higher
How to avoid this attack? more like flash add-Liquidity, then instantly remove-liquidity to get the reward right?
why will the fallback function be triggered?
How can we prevent this hack?
wow, impressive
This Channel is amazing!! How did you learn this stuff? 🤔
google, twitter, youtube
@@smartcontractprogrammer what youtube channels do you follow to learn?
Great video! Thanks for that! How to prevent these type of attacks when designing smart contracts?
What can be a contract 'A' in the code?
Hey! Are you using the vim extension for vscode? :)
yes
why foundry and not hardhat?
why not?
What is this contract for?
there is no way to avoid the hack here
if the developers reverse the sequence of loop such that the 0th element ie. ETH amount comes last in the execution of the iteration, will this vulnerability be resolved? It should look something like this:
for i in xrange(N_COINS, 0, -1):
value: uint256 = amounts[i] * _amount / total_supply
assert value >= _min_amounts[i], "Withdrawal resulted in fewer coins than expected"
amounts[i] = value
if i == 0:
raw_call(msg.sender, b"", value=value)
else:
assert ERC20(self.coins[1]).transfer(msg.sender, value)
log RemoveLiquidity(msg.sender, amounts, empty(uint256[N_COINS]), total_supply - _amount)
return amounts
i think it will
Please make more 0.8 hack solidity videos bro, they are helping a ton!
What does 0.8 mean?
@@0xsuperman solidity version
Great vid! Love ur take on security matters. Would have loved a “how to avoid part”, but this one is fairly simple to prevent.
Sry to persist, but could you make a video on bit-shifting in the v2 uniswap contract. With this im referring to the math behind the FixedPoint.uq122x122. Since your bit conversion video, i was left intrigued in how a bit shift would look with the dex values. Seeing as you can apply some logic to all bits in a 122 range for some purpose.
Love your videos!
Cheers
Curve should have updated all financial state prior to sending the funds out. The reason for this being possible is the callback function in the middle of a state change.
tldr; Don't be in an in-between state for important variables when external contract calls are made. Otherwise, the functions in use by other contracts could be manipulated via Read Only reentrancy.
Would you offer private tutoring? You really understand what you are doing.
How to prevent it?
Hello! What operation system do you use macOs or Linux ?
linux