Ethereum Foundation DevCon 6 - Security Track, 12 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

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

Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more.
https://archive.devcon.org/archive/watch/6/read-only-reentrancy-a-novel-vulnerability-class-responsible-for-100m-funds-at-risk/index

Reentrancy is one of the first lessons learned when getting started with smart contract development and security. In this lightning talk we will present a novel form of reentrency, the "read-only reentrency" which is mostly unknown, although devastating in today's DeFi world and which has been single-handedly responsible for $100m+ in funds at risk.

Speaker(s): Ioannis Sachinoglou
Track: Security
Keywords: read-only,reentrency,security

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

A

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.