Unlimited ERC20 Allowances Considered Harmful - Rosco Kalis - [Toronto Ethereum Developers Meetup]

Transcript

okay um yes thanks john um up next uh we have another very special guest um who is a native of the netherlands and someone i had originally met in lisbon portugal late last year um over our mutual love of a very very niche nfc collection uh called the bastard gambox version two um his name is roscoe kalis um i don't know if i'm pronouncing your last name right but roscoe kaelis callus and on twitter roscoe don's a particularly eye-catching and i dare say iconic avatar a front-facing bastard with wild hair thick neck and 3d glasses

what those of us in the bastard community call a grail um for the chain safers in attendance today who will be going to dev connect in a few weeks you know um lorna phil et cetera roscoe would be a great connection to make especially since he recently shared his top list of favorite restaurants in amsterdam on twitter i digress um roscoe has quite an extensive portfolio in web3 having first broke through onto the scene writing cash script a high-level smart contract language for bitcoin cash he then moved on to develop any hedge the first d5 project on bitcoin cash thereafter he spent time as an engineer for consensus where he expanded on the truffle suite by creating the truffle

dashboard as well as creating an integration between the truffle command line tool and ipfs slash falcoid most notably he became a mini celebrity and celebrity in february of this year when a number of high value nft hacks drove attention to the importance of revoking token permissions from your address the nft hoard by then had found and recommended roscoe's revoked dot cash website which had been presciently created two years ago at least according to the github source code he now spends time as a co-founder of chain grip which builds itself as a web 3 search engine and a new kind of block explorer and without further ado i'd like to

invite roscoe onto the stage um and roscoe you can uh the floor is yours feel free to take it away thanks thanks for the the great introduction it's probably one of the one of the most elaborate introductions i've ever gotten out of the stage so thank you um [Music] yeah let me let me let me share my screen i think i thought i thought for this um for this meetup it would be wait one second it would be fun to um uh uh sorry just gonna move this to a different desktop i thought it would be it would be fun to repeat the um

repeat the talk that i gave at ecc earlier this year on on token allowances so let me share yeah all right so i i didn't change any slides because uh the content is going to stay the same um so essentially my talk is about unlimited esc 20 allowances um and why they they may be harmful um so well i think i can skip this slide because uh tim already uh

introduced me so well um but yeah so most most importantly for the talk today i created revoke.cash a few years ago in 2019 um late 2019 and um revoke that cash allows you to inspect and revoke any any token allowances that you that you may have so uh what are we going to talk about first a bit about what erc20 allowances are uh why unlimited allowances may be harmful and then look at some case studies or like some cases where allowances were actually exploited and finally

some things that we as users but also as developers can do to mitigate those risks and um this talk is like specifically about esc 20 allowances but the same concepts also apply to erc 721 and 1155 so it's both fungible and non-fungible tokens um as their allowances work essentially in a similar way so first what are uh what are your c20 allowances um so essentially if uh if i have this die contract and alice wants to

um send it center die to bob then of course they can they can just send it directly um but with allowances they can also grant an allowance to bob and then they allow bob to pull the money to themselves at a later date and how that works is um that alice can send and uh can call the approve function on the on the token smart contract uh where they give um bob an an allowance and then later on bob can call the transfer from function which checks that that they have an allowance and then transfers the funds um like i said in this specific example you might like think well

this just sounds like a very convoluted way of sending money because alice can also directly send it to bob but right now it's alice and bob but it's going to be much more interesting when it's alice and alde or alice and eunice because with smart contract transactions it's not actually possible to send a token directly to the smart contract and in the same transaction also execute a function and whenever we're using smart contracts we do want to use functions because that's the the main uh use of smart contracts so

um in this case if i want to deposit some dye to ave i need to make sure that i have set an allowance to the other contract um before calling the deposit function and then the other smart contract calls the die smart contract with the transfer from function to sort of pull the funds towards the other smart contract and then execute any kind of logic that it needs and the same thing goes for something like uniswap if i want to swap die for each then i'll need to allow it first allow uniscope to spend to take my die first

um so if you have you ever used uniswap or or basically any kind of uh d5 application i guess um you're probably pretty familiar with uh with this concept like every time for example when you want to swap my unit swap or want to deposit anything you will see this sort of button here it says allow the uniswap protocol to use your tokens and um whenever you click that you'll be prompted to to sign an um and to to to grant the permission um and usually what these protocols do is they ask for unlimited permission

um but metamask also allows you to to enter a custom span limit and some protocols also offer the choice between the limited and unlimited allowance so [Music] one thing that may sound obvious with allowances is that when you are granting someone the access to your funds then you are granting them access to your funds for better or worse um so with smart contracts of course we know that bugs can happen and exploits can happen and with a huge with a regular kind of smart

contract exploits the the hacker will just steal the money from the smart contract but if allowances are involved in the exploits then the hacker cannot only take the money from the smart contract but they can also take the money that wasn't deposited in the smart contract because of these allowances um so something that people sometimes tend to do is uh with with new kind of protocols is they they will deposit only a small amount of money into the contracts maybe not knowing that their uh that their wallet funds are also at risk even if they if they only deposit a

small amount so um when i when i started revoked of cash in 2019 this this wasn't really an issue yet mainly because d5 wasn't really a thing yet uh nfcs weren't really a thing yet like everything was just in its infancy um but since then definitely um more and more exploits have been have been seen using allowances and one one of the first bigger ones was the bank war hack in 2020

in that case uh they they deployed a new version of the banker network and and um one of the functions was accidentally set to public which should have been an internal contract function so what that meant is that basically anyone could call this function and take users funds through allowances because that's what the function did in this case uh no funds were lost because it was all white hat hacked um but uh we've seen plenty of other other hacks this this was a big one last year um

i think it was in february february um for combo was uh had an allowance hack where a hacker pretended to be a new version of ave and was approved in the in the four combo smart contracts as being that that new version so then that granted the hacker essentially access to [Music] all the funds that people approved for gumbo and in this case it was 14 million dollars um and in in in these two cases these were pretty pretty big and established um protocols or applications that were

hacked due to like a vulnerability but it's also possible for just malicious websites to take advantage of of these allowances in the first place and one one interesting case that i that i like to talk about is the unicats this definitely wasn't a very a very big thing back then but you know of course during 2020 there were there was a lot of you know food and animal themed projects popping up most of which were not super legit and

of course unicats was no different um so the thing with unicats is that you could stake your uni tokens this was pretty soon after the uni uni airdrop and you would um you would receive meow tokens in return of course um so yeah that turned out to be a scam shockingly um but one of the things with unicast is that uh you know especially in in the summer of 2020 a lot of people were aware of the risks of the smart contracts they were

interacting with so a lot of people would only deposit very tiny amounts but like i said earlier with with allowances that doesn't really matter um so in this case anyone that deposited any amount of of uni into into this um into this application got like their their entire uni balance drained because of these uh allowances um [Music] so yeah and and and these these three cases uh were a while ago and i think that uh especially in the past half year or so we've seen a lot more actually uh also with nfts now um

yeah you know you we we've seen the uh the opens the openc exploits earlier this year with inactive listings that still got somehow executed because the allowance was still there and signatures weren't revoked um and then like like tim mentioned earlier in february there was a a huge um [Music] a huge crazy uh exploit where nobody really knew what was happening and in the end it turned out i think to be just a fishing hack or like a fishing scam but using allowances

so they i i believe they got um the victims to sign a message or like a partial uh order that then would allow them to just take any of their nfcs through openc uh by filling the the other side of the partial order um so that's pretty scary um and one other thing with allowances that one one question that i get a lot about it is you know i i got a hardware wallet because it's safe right it's secure so this can't happen to me right

but yeah in the case of allowances and a lot of smart contract based scams or hacks or exploits hardware wallets actually don't offer any protection um because what hardware hardware wallets do is is they they protect your seed phrase so that people can't can't get access to that but in in the case of allowances uh no one needs to get your seat phrase because they can they can take the money from your wallet without having access to your your actual wallet so then we can look at a few solutions both from the developer side and from the user side

from a developer point of view one thing that that makes a lot of sense is give the user the option between an infinite approval and a limited approval and in this case that's sort of a for the user that's kind of a trade-off where if you grant infinite approval to a to a protocol then that means that you don't have to send any more approval transactions but you also have some from some funds at risk whereas if you send limited approvals then

you [Music] if you send limited approvals then you will have to send a new approval every time you want to deposit more money or you want to swap tokens so it's kind of a ux for the security tradeoff and it's probably not really the developer's choice to make and that is why it's a good idea to give users options and let the user decide what they what they want to do another another option is some newer standards such as eip2612 which allows you to grant a permission with just a signature so without sending a transaction

and this allows us to [Music] to to make a limited approval every time without spending the gas for a limited approval every time you want to do something um the drawback here is that it's a it's a new standard and a lot of older tokens don't have this and so you'll always have to to deal with the older tokens as well um but if if you are developing a new new token um it could make sense to look into this oh sorry and um this is used by some by some uh

um by some newer tokens as well like the the uniswap v2 lp tokens um so then on the user side like i said it's kind of a trade-off between limited and unlimited allowances uh sort of security versus ux trade-off and probably a good way to make that trade-off is by evaluating who you're giving allowances to so if it's a um an established contract that is not upgradable and has been around for for some time has been audited then it's probably finer it's probably all right to set an unlimited allowance

for for a better user experience whereas if it's something that is new not audited maybe upgradable or changeable maybe not even open source then then you probably want to be more careful with the allowances so you and the swap you're probably fine you need cats you're probably not um and then the other thing that i also literally earlier is that as a user you can like even if if the developer doesn't give you the option metamask still gives you the

option so even if you can't um set a limited allowance inside the u in inside the ui of your application um you can always uh click this edit permission here and then set a custom spend limits um to be like exactly how much you need for now or if you want to to go somewhere in the middle you can also set a spend limit that is slightly lower than unlimited but more than what you need now so that you have sort of a buffer for for the your coming interactions um and then the final thing that you that you should probably also take into account is that you um

uh is revoking allowances so any allowance that you that you gave will be there until you until you revoke it essentially um and it's good to be aware of any of the allowances that you that you have given to two people over the years or to smart contracts over the years which is why i developed revoked.cache which is a very simple dashboard that lists all your token balances and allowances to to different protocols and different applications and it gives you the option to either revoke it completely or to update it to a

different value lower or higher i guess um so it's a good practice to periodically uh look at a dashboard like revoked of cache and just remove any any uh allowances to protocols that you don't actively use or that you don't really trust um there's some there's some links here as well um for for some further reading um these slides are also on my website i can put them in the chat here as well uh so you guys can figure this out later um but if if you're interested uh on my website goddess.me

uh i wrote a pretty in-depth article about the topics that i discussed right now um so if you want to like just read through that on your own time that will be the the article to read so then yeah are there any questions nope eric um i know you had a question you want to unmute your mic and ask it yourself or yeah sure um yeah i posted this question question in the chat but um like you know obviously erc 20s and 721s have been around for years and years but we didn't really consider i mean people talked about it briefly like maybe like in a blog post or something but we

haven't at that time even with you in a swap around like we didn't really see many people exploiting this approval function um or like you know this approval vulnerability i guess whatever you want to call it um i was wondering if you think you know that the recent attention towards it and all of that is due to maybe just like more savvy attackers on the network or if it's like i don't know just more like more mainstream adoption than people who are unaware of these types of attacks you know what i mean right right um it's probably a combination of both and i think um

like probably the reason why a couple of years ago it wasn't being exploited like you said there was uniswap and there were like maybe some other apps like maker um but i think in general there is just a lot more there are just a lot more applications uh nowadays so it's kind of bound to happen um these kinds of exploits like any other uh smart contract exploit like like back in those days there there were um other kinds of exploits that were in the news every now and then um and allowance exploits are just sort of

niche exploits so um they don't happen as often as just more the more general exploits um but yeah i definitely also do think that uh the sort of the the the newer people entering the space who are maybe less aware of of all the risks is uh definitely contributes to that as well because that just gives a a bigger target um for four or four hackers to exploit uh or an easier target at least um but yeah i i don't i don't necessarily think it's because of more savvy attackers

um but um yeah it's it's probably more due to due to just the bigger space in general makes sense aaron you uh you raised your hand there do you want to uh unmute your microphone and ask yeah for sure so i just want to know like uh can i compare with like those like a kind of practice as to you know like when you go to a gas station i will insert your credit card sometimes they ask you to set a limit right but if you do truck like kind of trust the gas station like you know people what people did like in the past they trust unit swap

maybe they have read through all of their smart contracts they trust them then there's no kind of attacks like because you're aware you know you trust this contract but then like uh nowadays it's just there's so many contracts you cannot just trust any gas stations anymore like any randoms smart kind of that maybe that's the reason why we we we need like um like a like a limit on it do you think they're comparable or yeah yeah yeah that's a good analogy actually yeah um yeah probably like if you're if you're somewhere in the middle of nowhere at a gas station that you've never used um

you're still probably fine with with credit cards i guess because you can always charge back but um you may want to be more careful and the same thing goes with with smart contracts um minus the chargebacks um so with with something like unit swap yeah you're like like i said you're probably fine like i i gen like with unisrop i generally use unlimited allowances myself as well uh for the convenience um but there's not a lot of smart contracts that are uh like that because there's also a lot of like even in established um smart contracts or in established

projects a lot of the contracts are like upgradable so there's always room for human error in in that upgrade in the upgrading process like if if you change something in the future then a new exploit might be introduced there so you're never completely um secure unless the smart contracts aren't upgradable and they're audited and have been around for a while so um but yeah yeah i think i think definitely um that's that's the right way to look at it like some some projects are are more trusted than others right yeah i mean i don't think it's even a matter of trust though right it's like

people trusted uh open c but they just simply had a bug so maybe it's just best to not use unlimited approval unless you know it's like a hot wallet and you really just don't care yeah yeah definitely um yeah it's it's it's it's a good thing you said like it's not just trust because trust can be built in through different processes um but something like uh yeah yeah that that's a very good point and um i guess in the case of nfts there's also the another like interesting aspect about this is that

like with nfcs you can give an unlimited allowance or you can give an allowance for like one nfc at a time and oftentimes people are selling like a bunch of nfcs from the same collection um so with nfts like it's it's even harder to give a limited allowance whereas like with with fungible tokens it's pretty easy you can just set okay i only want to spend a thousand die right now um whereas with openc you will have to like send 10 transactions if you want to say oh i want to sell token id one two three through ten

um so that is still something that that is you know kind of um not the not the greatest thing um we are still still kind of kind of shitty there but yeah right i do have a follow-up it's like you know what do you think of the design choice behind of the smart contract i mean i mean like in smart contract there is only like a one function right which kind of receives ethers um you know they could have kind of optionally make it make it possible for every uh function to receive it um what do you think of the the main design i haven't digging like into it but i never thought of the question you

brought up like like apparently uh it's very interesting yeah what's your thought on it yeah yeah so yeah this this this whole approval concept was created like like you said as a sort of alternative to the uh to like payable functions because with payable functions you can send and execute code in the same transaction but with with tokens you need to do to be able to do the same thing and and the solution they came up with in ese 20 was these allowances um but there are um like uh

there there are some other some other standards nowadays like the approve and call um uh standard which uh which essentially bundles these things in into one transaction um where uh um and uh there there yeah so so there are there are alternatives that might be better but it's also very difficult to like see every every angle and every possible exploits especially back when esc 20 was made um

so yeah i think i think you know ufc 20 right now that's what we have and that's what we can build on top of um and uh yeah i mean it's it's not ideal it's not ideal but i think the uh like all of the other um standards also have had their drawbacks um in in different ways so there's not really an ideal standard in that sense yeah thank you really really appreciate it thank you great and i i think that also kind of answers like jordan's question about what is the reason that this became a

standard in the first place i think you've kind of already answered that so um if anyone else has any questions feel free to unmute your microphone and ask away um [Music] yeah i see a question from you here tim in the chat oh yes yeah okay so i was just i was just gonna say like i'm not a sophisticated like crypto user by any means um but i like i've seen stuff like you know if you sign messages like that might be malicious as well so then with like eip eip2612 um if you sign a message like how would you know that it's not malicious um especially because with signing messages you never really know what you're

actually signing at least when i look at it it just looks like mumbo jumbo yeah yeah definitely um it's a very it's a very good question and you're absolutely right that um you know message signatures can be very dangerous um which is exactly what happened with um most open sea exploits actually that we've seen in the past year um especially the one that in in february um where you know a phishing website got people to sign a message which then essentially allowed um uh the the the exploiter to just take

any of their nfcs which is pretty scary um and this is more more so an issue with sort of regular assigned messages where you just have like uh a bunch of hex uh characters and you really have no idea what you're signing um so uh eip2612 uses i think 712 signatures which has like a a structured kind of data that you're signing so that's already better than just a blob of data so in in in this case for

example you're signing uh um this data you're saying okay this is the owner this is the spender this is the value and you know probably metamask can can do a bit of a better job in some cases to display this data um because this can still look like about but like a bunch of hex data um but at least it gives a bit more semantic uh a meaning and and um so at least you know what the data represents that you're signing and it's going to be a lot more difficult for um

like hackers or exploiters to uh to use that against you um because they have to like work with the the the the data that makes sense like if they if they're gonna uh if they want you to sign some data then it's gonna clearly list what you're signing so um but yeah like i think for like really um inexperienced users it's still an attack vector and it's still difficult like and and it's kind of difficult to really find a a good solution to that um yeah and then this problem is only going to get worse um as the space grows bigger and people become more and more

interested in nfts and you know it's it's it becomes really important to practice good habits with um uh you know signing messages and approving like token allowances and stuff like that so um roscoe thank you for your time um thank you for stopping by and giving us a presentation on token allowances really appreciate it i hope to see you in amsterdam dude yeah cool thanks uh thanks for inviting me over and also definitely looking forward to amsterdam