Arthur Gervais - Speculative Denial-of-Service Attacks in Ethereum

Transcript

ladies and gentlemen Arthur CH thank you so much for the very kind introduction um I use this clicker right okay all right so happy to present our uh more academic work today so this was uh work with my colleagues here from uh various institutions actually aiv yish he just finished his PhD at the Hebrew University uh cayin just finished his PhD in at Imperial College Lee is still a student of mine um and a is a dear colleague in uh in in Jerusalem as well um this work was uh also partially supported by the ethereum foundation so

thank you very much for this um um for helping us to do uh good research is this working this one okay okay got the right click on now sorry about that um okay so everybody knows uh transaction fees are a thing uh you need to pay for to execute code on blockchain so that's nothing new for you so there's a certain amount of gas that you need to pay and this gas is typically um you're typically liable to pay gas when a transaction is mined right so when it's included in a block now uh transaction

transaction ex executions on for example the evm layer can revert so a smart contract may may may have a condition that is not satisfied and then the transaction execution will not touch the state uh of a blockchain uh of the blockchain's execution and but these reverted transactions they still have to pay fees right um and that is largely due to the fact that we want to avoid D of service attacks so we don't want somebody to just Spam transactions that then revert and and do nothing and and don't cost anything so that's why they typically do cost a certain amount of money now is this enough do we need any other fee mechanism probably not okay good

probably not however so uh one of the issues is you can pay transaction fees for transactions that that are not included in blocks right at least Current Designs do not look for for such a setting so so just to give you a simple example right if you if you send out a transaction and it will never be included in a in a blockchain because maybe it doesn't pay sufficient a sufficient amount of fees then it it will not pay transaction fees do you have any idea any other case where it could happen that transaction will not make it into a chain nons okay some some uh some missing nons or outdated nons for example any other issues

Z zero gas okay right that's that's also an option any other ideas reor reor uh reok so typically transactions are that are that are that were in in a fork right uh they are put back into the mol so they can still be mined afterwards um but it's a good point right so it's a delayed inclusion so to speak very good yeah any other idea why would transactions not be mined that's such a weird concept no I extion sorry reverted execution reverted execution so then they're still included right the but they included executed but reverted so they don't affect the state of the blockchain but technically they they are included okay let me let me

spoil it so we have censorship right so since the ofac sanctions we have this concept that certain transactions we will not include in the chain and you may ask then okay where do we have sensorship like where on the blockchain stack in this architecture will we have sensorship um so here I I just drew like a a high level diagram of of the technical architecture right with these different layers P2P layer consensus layer application layer so there may be quite a lot of censorship here there may be some censorship here but also on the application layer if you use for example usdc or us they can Blacklist addresses that's also a form of censorship right

so you you actually have it on multiple layers in the system stack but you can also have it on the order flow uh part of the entire blockchain architecture so for example in ethereum we have this concept called proposer Builder separation right where Searchers are for example finding profitable transactions they're forwarding them to the builders the builders build blocks the relays take those blocks and forward it to the proposer or validator or minor or however you would like to call it um and so in this in this setting we do have quite some censorship going on as I will show you in a bit but to give you a little bit more of a definition of what is actually censorship or why does this

did this came about well there's the US office of foreign asset controls so the commonly refer to the ofak they have a list an sdn list the specially designated Nationals and block persons list so and there are hundreds of blockchain addresses actually also Bitcoin addresses on there um and most of them are externally owned accounts but there also some contracts and there also some test net uh accounts that were sanctioned um so that's that's actually the the rough concept so you might ask okay I mean has this any impact I mean we have a permissionless censorship free blockchain network right without any

Central party why would that have any impact well we we did measure the impact uh so the ofac sanction here hit at this particular date in 2022 and if you look here on the y-axis we have the number of uncensored blocks uh on the on the xaxis is the time and here we have different mining pools so at the time we're still in proof of work so um and you can see here right ether mine had had quite a lot of uh torado cach transactions right so TC stand for torado cach it's a it's a it's a privacy mixer uh which which was uh yeah I should add it was send it got so the torado cach addresses went onto the sdn list of ofak um and you can see here

there's a stark impact right of uh of what then happened in terms of um transactions that were mined uh or rather uncensored number of uncensored blocks okay so these sanctions they have a stark impact even on these very decentralized systems okay if you want to have a little bit more updated numbers on sensor sh right we just discussed the PBS system here um Tony um he he was so kind to create one of his beautiful websites that that really quantify the current state in ethereum so for example on censorship censorship. piix you can see 10% of the validators are sensoring and roughly 60% of the builders are

sensoring so why are more Builders sensoring than validators any idea yeah build are more Builders may be more concentrated is a good point Y any other reason think about the yeah they're they're doing the block building exactly they may be legally charged absolutely and that was a bit earlier in the in the food chain right so the Searcher sent the transactions to the block Builder to the relayer and then to the validator so the idea is in PBS is that the validators they actually sign

off on the blocks without even knowing what's in the blocks so maybe and I'm not a lawyer but maybe the majority of the liability actually goes onto the builders hence there are the entities that are more censoring right um okay just little side not so what are the security implications of censorship right that's the core of the talk today why does it matter censorship right we know it matters in terms of censorship and free speech and so but what what about security well we've seen that there's quite a stark impact on the average inclusion delay for tornado cash transactions right they went actually in August 2022 they went from 15.8 to roughly 30 seconds on average right so

transactions still get included but it takes quite a bit longer right um and the second biggest point is it opens up New Deal of service attacks so a note that is soring transactions has to do some work to execute the transaction but there's no fee that can be paid for that transaction okay and if there's only one thing you take away home from this talk I think that's it so if you censor transaction you may still need to execute it to know whether you should censor it and executing it but not including it in the block implies that you cannot it this transaction will not pay fees right and the N service

Vector okay so um getting a bit more into the the technical details so there's a concept also in especially in the PBS system where actors are executing transactions speculatively right so when building a block for example you may execute a bunch of transactions but if another transaction comes along and this one is suddenly more profitable well you're going to switch it right and then TX Prime here will not pay any transaction fees but you had to execute it so there's this concept also of speculative execution of transactions even though it's not clear which transactions will finally make it into the block so in our work uh that we did with our colleagues uh at the Hebrew

University uh we devised three types of attacks uh and these three types of attacks touch on three different system layers so we have one attack where we um where we have a conditional exhaust on the execution um on the ex execution layer of the evm and this is what I will talk about today in in in the later slides there are two more attacks one where we kind of trick theistic of a meol into dropping interesting transactions so we can Purge um we can cheaply evict profit profitable transactions and the third attack it's targeting a reputation system of the P of some of the PBS

actors um and uh so where an adversary can lower the reputation of other actors and thereby weaken their ability to make a profit so for the later two I will I'm happy to refer you to the paper if you're interested to know really the nitty-gritty um I will talk more about conditional exhaust but all attacks are really fully described in the paper here right um this was also accepted and peer-reviewed as usnick security 20 2024 so it it will also be presented um uh there okay so what about conditional exhaust well the idea is you have an attacker and the attacker sends transactions only when the upcoming

proposer right the minor here the validator when this proposer is OFA compliant right or aims to be OFA compliant so what would the attacker then do well the attacker sends a transaction and this transaction here um has two execution uh steps uh depending on the on the context so and it will check is the proposer that's now upcoming executing this transaction as a in a compliant way right so what does it mean to be compliant I'm using that word so casually here but just to be explicit any idea what I mean by being compliant

sorry uh exactly so uh being compliant and and I use it as a very loose term is to not mine a transaction if the transaction is involved so sends or receives money from an address that is part of the sdn list from ofak thank you yeah okay um so we can do these two things right so if if it is compliant we execute some complex code and then we transfer one address to some sanctioned address uh we we for example transfer one way so just some amount to to the sanction address and if it's um if it's not compliant then just execute some simple code and that's it right so that means that notes that actually um this will

trigger quite quite a lot of computation right to execute here this complex code and that's an denal of service Vector that targets specifically compliant actors in the space right so to give you an example um I'll actually give you solidity example in the next slide so this executing here the simple code would probably I mean for example can take roughly uh 23,000 gas which is only 10% more than the simplest ethum transaction we can think of but the complex code here can take a lot of gas for example 30 million gas if you'd like to right so these are really like the kind of like two branches that we can

design and therefore Target specific actors that are sensoring so how does this code look like well it it is rather simple uh I would say so here for example we have uh we have this contract we have a Constructor where we where we Define right which addresses to Dos um and what's interesting here is I think the way that we do this particular version is that we look at what's the future what's the address of the future of the next proposal right so we assume that the adversary in this particular case knows who is the next uh proposer which in proof of stake uh we we typically know and the addresses also of the validators are are fixed until they

uh withdraw from the proof of stake chain so this is this is a possible way of of carrying out such an attack does anybody here so and this is a bit more technical does anybody have an idea on how we could what other mechanisms we could do to execute this attack or to ident Target like the next validator besides the coinbase address any other ideas random yeah but then sometimes we have to pay fees right for the for the 23,000 gas uh and sometimes we're successful so we we can do a bit better than random yeah time stamps time stamps is not bad and there's something that's

very close to time stamps block height yes correct absolutely so we have we we have this we described the second version actually in the paper so feel free to check that out if you're if you're interested as well very good um so we did an evolation on on on our machine with 64 cores uh and and quite some rum uh the flashboards mean specs are are much weaker so we took really a beefy machine right that is kind of like the victim note that we will be attacking and we found that a one shot of 140 transactions so we sent one 140 of these sensor exhaust transactions one shot um would would kind of yeah propose would force the the proposer to mine

empty blocks even if the proposer is mining 100 consecutive blocks which I I know understand this is unrealistic but it's a very favorable case for the for the proposer right so the cost of this attack is is less than $1,000 so I I guess for for the impact on liess of the blockchain this cost is really negligible um yeah so there's a call to arms right we the the consensus the consensus and transaction fee mechanisms I would say are relatively well understood obviously there's always uh room for improvement and and more and further re research to be done but for transactions that do not enter blocks that's really the wild west right so we

have we have quite some work to do uh PBS and the separation of roles certainly add complexity and make and introduce novel attack Vector so it's really complicating the system um and yeah in I think in in Prior work right in Prior work uh people said proposals future proposals can be attacked because we can we know who is the next proposer for example we can Doss them but what I really want to show in this work the the future proposers can also attack right so if we if we ignore the the censorship part there are also attack variants which we described in the paper where the attackers can the the proposers can attack themselves all right thank you I hope this was uh

an interesting uh yeah talk for you thank you so much thank you so much Andrew shway are there any questions we have time for one or two short questions any questions uh sorry who who's asking the question Sor can you I think I saw your hand first can you okay thanks uh I will ask first uh what if the uh the decision if the proposer is using a OFA compliant Builder is not known prior because the

proposer is using more Builders let's say one compliant one uh not compliant sorry I would you uh execute this attack if is not known if the Builder will be of a compliant or not so if the if let's say if a builder is receiving a transaction right and the Builder has a certain policy am I compliant or am I not compliant right the question is if the proposer is using more Builders if the proposer is it is not known if the one that will build the block is compliant or not you cannot known that well you you do know you do know whether the validator right from

historical data you do know whether the validator the next valid so so first you know the next validator right that's that's proof of stake then the second thing is from historical data you know whether the next validator whom you know whether this validator is sensoring or not I don't think so but okay I mean we we have we have the data right we we can we can go here um oh I cannot I cannot switch anymore but we have this we have this 60% of the builders are sensoring right 10% of the validates are sensoring so we we do know who is censoring right and then the builders where they typically do is right they know okay this validator is sensoring so I'm going

to have to sensor also right it's kind of like a the Builder it the Builder has no intention of building a block that is that is not compliant for a validator that wants compliance okay thank you so much and thank you uh also to the audience