Read-only Reentrancy - a Novel Vulnerability class responsible for 100m+ funds at risk

foreign [Music] my name is Janice and I'm a smart contract auditor I work for Zen security and for the past five years with State security we have secured some of the most famous divide protocols and sometimes we find very interesting attack vectors as the one I'm going to describe today actually this attack was found by a colleague of mine named Canon so first of all why should we care about this attack why this attack is so important so it's actually quite a quite novel attack not many people know about this and it's often neglected by both Auditors and Developers so this attack is based on the interaction between different protocols and these interactions get more and more popular since you know we build based on these the five blocks what makes this attack more interesting is that it actually affected protocols that integrate with curve Finance one of the most famous expenses out there and as a matter of fact the total funds that were at risk were more than 100 million so we're talking about a lot of money here so first of all what is re-entrancy so our industry takes place one an execution of a smart contract is interrupted and the state has not been fully updated and the control is passed to another smart contract which can then call again a function of the smart contract whose State hasn't been finalized and up until now the traditional re-entrancy was concerned only um with entry points that modify the state but as we will show this is not the case here so just to give you the textbook example of a re-entrancy we have this re-entrant contract and users can deposit and withdraw ether from it and actually when a user tries to withdraw then when the native ether is sent to the receiver the receiver has the opportunity to run arbitrary code and what a receiver a malicious receiver can do can call this withdrawal function again and since the state has not been fully updated and his balance is not set to zero they can successfully call withdraw all again and essentially get uh more ether than what they had deposited so this can be easily fixed and people deal with this problem by introducing this non-rental modifier so if we visit the same function again we cannot call withdrawal again when we receive a data because the lock is true and the whole transaction will fail however nothing prevents the malicious user from making a call to another contract which reads the state of this contract so if someone reads a state at this point what they're gonna see is that the total supply has been reduced but the the the balance of the user has not been set to zero this means that the ratio for example is not going to be correct so this is a different attack from the known re-entrant scene so uh let's get to to care and what happened there as you know AI curve is a decentralized exchange there are many pools in Kev the pool that was affected by this attack was the a pool that contains native ether and a staked ether and as you might know users are liquid providers they can add liquidity to a pool and of course they can remove liquidity so what happens when users remove liquidity well first the lp tokens they hold is burned so we can think that the total supply of the lp token is reduced and then one by one the tokens are sent to the user and the first token that is sent is native ether so upon receivable of this native ether a user a malicious user has the opportunity to call an arbitrary uh to make an arbitrary call of course I cannot call a curve because it's protected by a non-render modifier however what they can do is they can call make a call to another protocol that for that reads the state of this pool and how protocols usually read the state is by using this get virtual price function that I have down below so let's inspect this a little bit so the get virtual price depends on this D factor which depends on the balances remember we have only updated the balance of the ether but not the balance of the state either and also depends on the token Supply and remember we reduced the talking Supply so what we achieved here is we essentially pumped the this get virtual price so this function is used to give an approximation of the value of the lp token so imagine that we have a protocol that holds these LP tokens during this attack the price of the lp token is pumped and then the protocol will think that it holds more money than it should read only reenterence is still a real interest in the sense that the storage is the storage update is not fully finalized but the big difference is that we read the state we don't try to access a function that modifies the state of the function so how can we prevent this attack so one way is to to make this lock that I showed you before in the non-rental modifier to make it public this works for new protocols that you know are being developed but what can we do for all protocols well the thing the solution that we've seen uh to be more efficient is when you try to read the state of a smart contract uh first try to call a function that is non-rendered protected if this call fails then it means that you are in the middle of our entrancy and you should then read the state of the contract so that's it for me actually we just published this attack feel free to to read more about it thank you very much [Music]