ChainSecurity | Matthias Egli - Reentrancy in Cancun hardfork: curious case of EIP1153 | ETHDam 2024

[Music] okay our final Talk of the day I'd like to welcome Matias from chain security thank you very much welcome everyone um so I'm happy to be the last one and then that afterwards there are drinks so let's get started this one will be not a workshop this is a talk about um pretty like deep topic and change which happened to ethereum in the last upgrade the Cancun hard fork and how it uh enables a new form of re-entrancy attack so I'm Matias um I'm CTO and co-founder at chain security um we audit a lot of the large D5 projects um have been doing this now for almost seven years um mostly based out of Zurich very happy to be back here in Amsterdam um and um what we also do is like research new vul vulnerabilities develop tools and part of that is what you will see here right so this is out of basically us taking a step back from Audits and then realizing oh wait what did just happen right and then this kind of research uh sometimes leads to novel vulnerabilities and um I want to present this one here so let's get started the talk today will cover four topics we'll uh first go into a quick recap of what changes happened during the Cancun upgrade to the execution layer we'll recap how do execution context messaging works like this is a fancy word for basically contract calling another contract and how do they communicate um or in this special case how can they communicate when calling themselves again then the New Concept of transient storage um how it works what it costs and so on what it enables and finally the new re-entrancy uh which is possible with transient storage um if you don't use transient storage in new smart contracts which are going to be deployed now right it wasn't possible before if you don't use them carefully so quick recap what happened at Cancun hard Fork um for most Cancun hard Fork is a one which introduced like blob transactions right cheap uh outside of the evm storage uh The Blob base VI op code is related to that um we nowadays can also validate what happens on the beacon Chain by uh committing a proof because the block uh the beacon block route is now available small optimization with M Copy self-destruct is is really not self-destruct anymore in almost all cases right you cannot delete code with self-destruct except in the same transaction and this removes a certain class of um attacks which is great um and then finally EIP 1153 which is what I'm talking about today so transient Storage Shop codes so the recap so how does data uh work inside of the evm uh before canun before the upgrade right you have the evm it knows like an instance of the evm is like when you call into a smart contract it gets spawned it knows obviously its own code right um it knows it can access storage which is uh only accessible for that uh like from that address from that smart contract how we think about it and then it has machine State most importantly the memory right but also program counter the gas availability which is by the way a way how smart contracts could theoretically communicate a little bit and the stack but but this is volatile right so what happens if a smart contract wants to like pre Reserve its context across calls the examples I'm giving here is like there's one smart contract C it has a function it then wants to pass something to itself like a function being called in itself but not directly right there is an other contract involved now this contract might be one which is like immutable and very well understood right and a contract which can not be malicious but it can also be a malicious one and what we are concerned about here in the form of re-entrancy attacks is of course if contract a is a contract which is controlled by someone we don't trust so how can they communicate it's important that they cannot communicate with memory because the smart contract C at stage C1 um has its own memory compared to the one at C2 right it will not be able to access it you can use call data to communicate which basically means uh makes it that C1 sends some call data to a and trusts a to send the call data on to C2 but that is only possible if you do trust a and so in general this is insecure you can also use Storage storage um is very expensive to access so um the uh lowest amount is 2,900 gas and up to 20,000 right to um have a storage a new storage right you can regain some of that cost um because there is gas refunds they are limited though it depends on what the transaction is doing otherwise if you spend enough gas and it's okay if you don't spend a lot of gas on other things then you actually might only be able to recover parts of the refunds so this is how it used to be and here comes transi and storage the so the idea is inside one transaction you can communicate Che like keep the storage around it is presented as think of transient storage exactly like um s store like uh contract storage which is permanent except for one thing it resets after the transaction right so this is the mental model which in generally you would want to have people to have about transient storage it's much cheaper it's just 100 gas to read and write to it and um with that you can have this cheap way of communication where like C1 stores something which C2 then later can read and and a cannot manipulate it right um so the big use case of transient storage is re-entrancy guards and here is an example of how that re-entrancy Guard works I'll quickly go over it so um it's very simple right initially you check is it is a smart contract uh secure in the sense of it's not in a context where it has been entered before so you check that the lock is not entered you set it to entered the modifier then executes whichever code is protected by it and afterwards it uh resets the lock right and for details of like gas optimizations not enter this one and enter this two instead of zero and one because this way you save a little bit more after the first um after the first call so this is how it worked when you communicate with storage how it works today in ethereum and the cost of this is around 5,100 if you don't get a refund 2,300 if you get a refund we can quickly calculate that so you need to load it first with it's a cold s load when you check it it's 2,100 gas will'll then um write to it but we recover a lot of that cost uh often so the ride is 2,900 and then we later ride it back to not entered which was a state it was initially right except for the very first call and then uh we pay 100 gas or 2,800 depends on those two cases with transient storage this gets a lot cheaper so for now solidity does not support um the modifier um or like doesn't have a direct keyword for it so you need to use assembly um this is basically the same you saw before right so we will load uh we will check but we use t- load now then um if uh if that was set right we revert we store that it has been entered and then afterwards we reset and perhaps there's this question of why do we reset afterwards if the transaction like the property of T store is any way it's going to be reset after the transaction and the reason here is is composability if we would not reset here after the modifier in the same transaction if someone calls it it's still locked right it means you cannot batch transactions easily this is not the malicious use case of a re-entrancy this is a benign use case of batching and you want to enable that so you need to reset so this adds the 100 gas at the end so in total we are looking at 300 gas for a re-entrancy loog with with this mode um with t store much cheaper um and there are ideas to make it like to reduce the cost like the 100 gas a lot of people think it's like a defensive initial cost and over time with uh uh depending on how the um clients implement this it can also be reduced even more so now this is a simple smart contract um and um there's no transient in use here right um it's a vaed you can deposit you can approve someone to spend money and you can withdraw everything from an address if you have the allowance to withdraw from it can someone here spot the issue in this code of like what what's the problem with the code yes exactly so this this is the idea here right there's the one caveat some of you might notice this too right is this really a problem in this special case it's not this is a transfer this is not a call transfer has this property of only passing on limited guas 2,300 and then that limits what you can do with it right this is the good old from the very old days of ethereum uh re-entrancy protection which was added after the Dow hack um to to prevent these kind of uh re-entrance if you basically just want a sense some ether around um this used to be a problem and uh quick recap on this so you might have seen before right you can actually ride to storage with just 100 gas if it's warm right and then you can have this re-entrancy attack and um initially when the Constantinople upgrade was done there was the plan to implement it as such and it would have enabled re-entrance attacks then uh back this is like by now it's quite some time ago um shortly before the upgrade happened we um we found that this is a problem right and then uh informed ethereum the ethereum foundation about it and this ended up in a delay to that hard Fork because a protection was added in the end right there was some discussion around it of course in the end what we decided to do was to Simply say if there is only 2,300 gas left and you try to write to storage even if you could like if there would be enough gas we'll just revert right so this is why this code is safe right and a lot of people when they audit code think of re- entrances then they really make sure that they don't need to check if there's a transfer because they by default know nothing bad can happen but here comes the problem right so what is possible now with EIP 1153 here we have a version of this contract which would use some transient way right and at this point when you have the very same code and you do the transfer now the attack you described is possible because you can re-enter here you have enough gas there's no reset going to happen because you below 2,300 gas and you can re-enter again and of course um attack the contract this way so what is very important with transient storage you need to be aware that when there are native ether transfer calls they don't protect you against re- entrances which um modify transient storage I have a example we found when we we found this and we looked for what's already out there right this was found when um like Cancun didn't happen yet uh it's also a known issue in Cancun right this is not a surprise to the ethereum foundation and so on um but very few people know about it um so this was an example which we found in the wild where uh Viper which has this keyword for a little bit longer um used it this is an example where you do a deferred liquidity check right and then again you have that problem um I'll in the interest of time not go through this um so the important takeaways here like first the mental model of t- store t- load is generally fine right think of it like this data which is available for the lifespan of a transaction it is mostly equivalent to s store s load it's much cheaper it's 100 gas and it allows for re-entrance during transfer right so think about this because this might make some transactions you did in the past which used to be secure now insecure I'm personally I personally think we see this mostly about temporary approvals this is one of the use cases which T store was meant to handle and um you saw it in the example right with with approval being basically the thing which was attacked so this is a likely case um but we'll see more over time right uh the creativity for attackers is is very high um so uh with that um thanks a lot do you have any questions so did the re-entrancy attack basically just become possible because the gas is cheaper now with the with the new storage and then there's more gas still available uh to do other actions sorry you probably mentioned it but I I I couldn't come to the conclusion myself yeah no so um this attack is now possible because um while s store um will fail if you are in a low gas environment which um this 2,300 gas on a transfer uh uh creates right basically the smart contract will be in a low gas environment at this point um t- store on the other hand does not check if it's in a low gas environment and will work so you can have storage rights to the transient storage but you cannot have rights to the um uh like persistent storage and the re-entrancy uh requires you to change storage right otherwise it cannot work so uh here transient storage is attackable uh like permanent storage isn't um and and this is now possible because of that it will not make any contract out there vulnerable uh because they all use like s store right uh only if you t St then it in the future if you deploy a new contract with which uses T store exactly then this could be possible that it can be attacked and if I'm allowed the second question um the T store is only callable with assembly do you think it will make assembly more common because right now we don't see it that often and a lot of clients actually are actively forbidding it for example we do a gas optimization competitions as well forbid to use assembly uh from the participation yeah um no I it will become a keyword right it is a um something which people will want to use properly um solidity if I un like I just heard that it's uh very close to to be released um Viper already has it yeah I'm sure there will be a transient keyword similar to what you saw in the example uh for people to use even if for now the code you will see will use assembly um and um gases and will stay very expensive on ethereum people will use transient storage um also in the context of like account abstraction right with a with the batching calls and so on you can really save here thank you there any other questions all right thank you very much that was super interesting [Music]