AllWalletDevs #11

Transcript

uh we have two things today and Heap 712 implementation uh problem that came up recently and an update on the wallet testing framework by myself and Nikki uh so I'll head it off to Matias and uh let's get going cool so first of all thanks Sam for inviting us to discuss this issue that we found like two or three months ago uh it's been quite a challenge to you know coordinate the disclosure and and also to let every involved party uh know about about the issue okay so I'm gonna talk about myself uh like very quick uh I I come I'm coming from the

web to security area I was previously a consultant at an another uh consultancy company uh I'm from coinspec um there we've been working in the blockchain security since 2014 and yeah we do every kind of security audits um from Smart contract to off chain code um okay that being said uh so this issue I'm going to present today is part of a bigger research project that we've been working on at coins back a couple of us uh not this is not a full-time project

uh we've been doing that in our free time mostly on we um or when we are of audits or or another you know consultancy projects so uh we realized that the wallet security field is was very little explored not as much as smart contracts for instance and the approach we took was first starting as a black spot black box testing um like you know testing all of the user experience of the of the wallet to assess whether that user experience was Secure and now we are focusing more

towards the source code uh of course whenever whenever we have source code there aren't many source code wallets out there but still most of them share code base and share the same architectural patterns so yeah that's it and okay so about the goal of This research project is to overall to contribute to a better uh and more secure user experience um our goal is to assets multiple wallets at once and try to discover issues multiple issues

affecting more than one wallets which is the case of these EAP 712 issue um and then like aside from doing the research we I will also later comment about the our upcoming work or our upcoming ideas for these you know high level wallets research projects so what's the eaps 712 issue about I know if you guys were able to to read about the issue the thing is that the problem itself was was not as impactful as you know we are used to actually this is a

lower medium security issue I mean the risk I mean but the the what's interesting here is is that it affected more than 40 wallet vendors um I think that there were just three or four that were were actually validating his problem one of them was metamask which we most of the time consider as a security standard because they do a pretty good job at it so the problem here is that many wallets didn't validate the the chain ID the that

that that's in the EIP 712 domain um that so the wallet didn't validate that the chain ID of of this domain was the same chain ID of the chain the user selected in the wallet so I'm giving I'm giving a practical example let's say I'm using my wallet with in the Ethereal Network and a malicious app could have signed a a an EAP 712 object for let's say the arbitrine chain and unless I'm an expert at chain ideas I I couldn't have noticed you know this

problem and could have signed these EIP 712 object which would have allowed which could have allowed the attacker to you know to obtain let's say a permit for the for another chain than the one I selected um so yeah the relevance of this issue is more about the the number of vendors that were affected more than they should solve but that's our goal to you know keep finding issues like this that are shared across several wallets we also found a couple of other issues that were also reported along this

journey uh also related to EAP 712 for instance some wallets were now displaying we're not displaying the EAP 712 object be to be signed at all or we're not displaying the the eip-712 um domain part which is I mean the the EAP 712 domain has like five different fields one of them is a chain ID then we have the verifying contract there is a a salt and a version for instance so some wallets fail to to actually display that uh when asking users for

for their signature Okay so regarding our experience because this was an experience I think that it took us like almost three months since we since we started to discover a pattern across different wallets and inspiring for pattern I mean starting to see that most of the wallets fail to validate these chain ID um so since we started to discover that pattern until we were finally able to publish the blog post it was a an entire experience so we realized that many

vendors uh actually host or I think it was almost a 50 of wallet vendors hosts by grantee programs and but yeah most of the vendors that host uh background programs are them well established wallet wallets but the program we found here is that not or I'd say most of the vendors they don't allow the disclosure of bugs um I mean once you report it uh they say hey uh I don't want this bag to be disclosed but the thing is that here we found that bugging like 39 more other

wallets which is kind of you know uh difficult for us then we also found I I know I think that it was for vendors that didn't even have a contact UM channel that we couldn't reach out to Summer vendors we that we were able to reach out they didn't get back to us whether no comparing the issue or not giving us any feedback at all um also like while disclosing the issue then

we we try to you know reach a a common disclosure day the thing is that many vendors kept on asking for an extension of the day so that they could you know publish their or I mean deploy their their patch and I think there are still some vendors that haven't deployed the patch um and also we found a couple of vendors that said hey uh so since this is a malicious app then your bag is not in scope

and that's funny because I think that in the in the thread model of any wallet you have to consider malicious apps um otherwise why are we asking you know permission to connect to adapt if it's small if if we consider it not to be malicious right so that was funny uh we have a we have a couple of bugs rejected um also if you guys want to head to uh the coinsback Twitter profile you'll see a a an exploit that we we published a few weeks ago foreign they were not willing to you know uh

recognize they had a serious bug so yeah they were one of the one of the people that didn't didn't want to acknowledge the opponents so I I talked about this high level um software wallets research research project uh so what's next um the things that we've we we kept on you know investigating the multiple wallets uh actually in the upcoming weeks I think that we are going to publish another problem that we found related to the the transaction simulation in a well-known wallet

uh so stay tuned uh give a follow to the coins coins back profile um Okay so then we are also thinking in publishing a wallet checklist that could be used as a guideline for for both uh wallet Builders security Auditors and even users uh so and this checklist was the result of the research that we started because we try to systematically do an assessment to each and every wallet so this checklist was a sort of an internal

tool that we are willing to publish and and with and that we think that will be will come handy for people out there so if any any of you listening to this talk are looking to collaborate with us we are open to collaborate with people and we can figure something out um otherwise also stay tuned uh for updates I think that we will shoot soon be publishing the the checklist in in the next month and finally if there's something that you guys don't have time to investigate or or that

you'd like to ask to investigate about uh just please ping us we are happy to do so in our in our free time and I think that that's it I hope to have been pretty quick and so boring so thanks guy for for listening to this talk I know if any of you have any questions thanks so much for sharing that's awesome I'm quite surprised that wallets don't show the the 712 domain I feel like that's like really important information to display so yeah yeah I I think that we found I think it

were like six wallets that didn't show the the object at all and six six other wallets that were not showing the domain part Which is less of a problem but it is still a problem right because an attacker can just you know sign whatever they want and they use the one down that's funny yeah exactly so this checklist is that going to be something that might be automatable uh or some pieces of it it's not it's not meant to be automatable uh because there are a bunch of you know code source code checks and

but I think that's something that it could be done with you know a certain work but at the very beginning it was meant to be more of a let's say an almost uh uh checklist for for software wallets but we are open to any ideas and suggestions of course so the reason I ask is kind of a transition into the next topic um we're building a testing framework and if you have if any parts of that checklist are automatable like you know the wallet should display the 712 domain that would be a good uh a good test to add to our framework so I'd love to

collaborate with you on that okay so yeah let me let me scan again our checklist and see what could be automated with a decent amount amount of work I mean without being too too hard yeah that'd be great so yeah cool Sam so thanks for the space thanks for inviting me uh thanks for coming we really appreciate it thank you all right so um next up I guess uh is is me and um Nick here if they're here uh we've been working on the wallet test framework

that you've hopefully heard a little bit about and if you haven't uh go look it up uh it's a collection of tests that we're building to share as like a common good between wallets um to ensure like a basic level of consistency and quality uh we have our first uh half dozen tests written right now and uh yeah we're getting ready to you know ramp it up and build some UI Automation and uh yeah so far we've been using frame and metamask as our test wallets um if you you know like to try out your own wallets uh there are instructions on the GitHub repo and I'll post a link to that after um I have a little demo that I could

hopefully um oh we'll see if it works um yeah so I'll just hop right into that okay all right so is that working yep okay cool yeah so this is what it looks like today um it's a small NPO or node.js server that proxies connections and uh

I have to turn you through it so the first step is that it adds a a fake ethereum chain that connects to ganache running inside the browser we're using mocha as our testing framework and it makes these nice little HTML summaries so everything that's going on right now is actually testing against the simulated blockchain and proxying through the node.js backend server uh so far we don't have any UI automation tests that's going to be coming a little bit later so far we have just some tests for basic RPC endpoints like getting the chain ID

getting you know transactions and that your balance updates uh after you receive money um so nothing too fancy or complicated right now but uh yeah we're getting there and hopefully by the end of the year um we'll have a solid testing framework that wallets can choose to adopt or not and hopefully we get some contributions from from everybody are any of these going to fail I want to show a failed test no all right cool so uh yeah that's uh about it for for that um does anybody else have anything they'd like to demo any questions uh any conversation topics

I have a question about that you said that you are having your own blockchain running there what is the editor or the metamask connected to your RPC server there or how does it yes exactly so metamask uh adds a new tech like we call wallet at ethereum chain um with uh like a unique URL that gets proxied over websockets back to the same browser and it's connected to ganache running in that browser instance okay well I think it sounds a bit bad idea that you are adding the chain and The Meta must accepting that I feel that that's not big enough that that shouldn't work like that in the future so maybe the users would edit themselves

but I guess that would be instructions for that as well yeah so um once we get some UI automation working um so the design is kind of going to have a piece of glue that's unique to each wallet that knows how to click buttons and and things in the UI um and that is how we're going to add the wallets in the future uh as I'm sure most of you are aware I have Eep 5139 which is all about getting rid of wallet at ethereum chain but for now this works really well um but it is something we're planning on getting rid of so at the moment doesn't work if you don't support that feature

exactly yeah but uh that's probably gonna be the first piece of uh automation we do yeah okay yeah there's totally an empty slot today um love to have you demo whatever you've been working on um any other questions on wallet test framework uh if if not we'll move on to Victor okay so floor is yours Victor thank you thank you Sam thank you everyone hi uh everyone my name is Victor and I also go by X I am the NLB if you encounter me on GitHub or

ethereum Edition um I'd like to demonstrate to you a new uh update on the uh ERC ref um I came to this a group a few weeks ago uh demonstrating the general concept of yati ref uh basically we want to build a repository for people to share the reference implementation uh to the uh to erc's so authors contributors developers feel free to come over and uh today I just want to share one of the new thing that we called uh yes yes20 token with fees um so uh I I think it's an interest in my interest the wallet group because a lot of you um operate in helping people sign

contract signed transactions to transact and so um there's a general concept that's uh usually um an erc20 transfer doesn't incur a commission on some of the community members in the industry has started to discuss whether it's possible to or should it be a new Norm to incur fees so uh in that case um for example usdp as one of the biggest uh one of the top three uh staple coins has a in place um fee um default to zero right now um set up so that they can in the future change that parameters to charge fees

whenever a transaction happens so a reference implementation has been provided in this particular smart contract where you can deploy it in test with your wallet Whenever there is a transaction there's a fees that is incurred and then to see if it works there is a test we also wrote to just demonstrate how it works and what is to be expected and uh so yeah this is what I want to show and in general the ERC ref contracts is we want to build a library so that you cannot not only share your smart contract but also um learn from others and then ultimately we want to build something similar to open Zeppelin but a more bleeding edge right for this ERC that's even in draft

or for ercs that's mature but you have new ideas like this this is hopefully a place for you to kind of check out and and come to contribute so contributions are welcomed uh check out ERC ref of the git in a GitHub or our uh website and that's it thank you uh our wallet call meeting back to you Sam awesome thanks anybody have any questions on ERC ref cool so um that wraps up I think the

scheduled discussion for today um yeah so um unless anybody else has something they want to demo or talk about we can wrap it up early today yep Adam yeah I just wanted to quickly show the human readable transactions working group put together by Kong from uh sourceify we just had our kickoff meeting this morning um it seems relevant to probably most of y'all uh if you work on a wallet you got to display transactions to users somehow so um just linked the the Twitter posts um in the chat and also in the general Channel

I do have one thing we're trying to get a standard into the various clients for each multi-call this is basically the same as this call except for you can do multiple transactions and they'll all build off of each other the same way transactions in the block build off each other and you can also do things like telling the underlying execution engine what the block timestamp is what block number it is things like that the idea here is that this solves a number of different problems um for both staff developers and Tool developers and integration people doing Integrations people doing um it also allows for people to do Mev without needing to be experts in

scripting because you can just you know ask your node um anyways drop the link in the chat I strongly encourage any wallet developers to give it a look because it may impact um a what's how your wallet works and but more importantly it may allow you open new doors for your wallet and so we'd love to get more feedback and support from the wall community on it have you posted a link in the proposals Channel uh again thank you Victor uh oh thank you uh Macau

um good to meet you here a question for this is that does it mean that the uh people will uh no longer were less likely to need to use any on-chain smart contract bundler uh because the evm will support that the execution will support that out above so you can make a call directly this is only for off-chain calls meaning like each call type stuff this is not for forcing transaction ordering which is a separate thing so like if you want to make sure that three transactions land in a row on chain um this will not help you with that directly at least this is more if you want to say okay what happens if I do X then y then Z and I want to see the feedback so the way for example the way

we're using it in our tool is we're making it so people can utilize ethereum based applications like uniswap and curve and whatever and they can kind of go through the process of using that app but without actually committing anything to the chain but they'll see the chain as though they had done all those things that's how we're using it and they can again it could be used in a bunch of different ways but this is all just just for the eth call side of things not for the send transaction side of things oh I see got it yeah um thanks that's very helpful that's it if I just to make sure that I understand correctly it it also means that it's just for local check and then wait a minute um so does it does it

require it at any case it's being used to to send in transaction it also does not insert automated CT of those transactions together once you once you take them to the blockchain correct it does not ensure any at an autonomous I also struggle with that word um it does not have any um it doesn't give you any guarantees on that front once you go to the chain this is purely for um simulation so a perfect example of this is if you go to uniswap you need to do an approval before you can send right and so if you wanted to see what happens okay if I do an approval then I do Ascend in uniswap you can do that by doing a multi-call of approved then sends you stack them together you send them both as one thing

and the result you get is the send works so normally you can't simulate the send or the transfer the token transfer until after you do the approval the approval need to show up on train before the blockchain like the client they're using will actually let you do the the transfer with something like multi-call we can now do the approval and transfer in simulation mode and so we can now you know prep multiple transactions in a row and so uniswap could for example if this got standardized instead of having to prove and then send me two separate steps they could potentially you know cue them both up and then um and make sure and then get them both ready and then submit them at the same time they still have no guarantee of ordering other than nonsense so you

could have something show up between them in terms of the transaction order um but due to not saying the approval show at first then the transfer will show up second but you can send them both to the chain at the same time theoretically and so the the hope is is that this will allow you know better again the thing we're using for and the things on my mind is simulations and so just letting people see what's going to happen before it happens right now you basically here's a simple example I was using a tool other day that lets me let someone invoice me and then I can pay that invoice and so the uh contract I was calling wanted to want me to do an approval before I did a transfer and the approval was for more than what I expected like it was a

bigger number and I wanted to understand what was going on there and so I was able to simulate the approval and then the application saw oh the approval is done and so then I was able to simulate the um the transfer and then I could see okay the actual transfer is transferring the correct amount and then I could simulate a revoke of the approval at the end to make sure I ended up good and everything went went smoothly there's still a little bit of risk because someone could in theory sneak a transaction in between two of them on chain but in this case it was enough for me to be satisfied that everything was was up enough um and our hope is that we can provide that sort of flow to to more users where they can kind of cue things up see what the final outcome is and then submit it

all at once and then maybe at some point in the future we'll work on standardizing um something in the consensus layer where it actually guarantees autonomicity between a stack of transactions but that's probably pretty far off yeah that thank you for explanation that that's very very helpful uh and I think it's a lot of value to allow people to see uh the outcome of a set of transactions going in together and what the final outcome is what I have like if there is I like if I were playing the uh The Devil's Advocate a little bit uh the only thing is that usually people will think like not end

users will think that is either go through or not uh in this particular case because it's multi-core there is a conflict uh complex possibility that some of them will fail in in the middle and then therefore uh unless the consensus team provides a consensus site provides us autonomous ethnicity uh otherwise uh we'll need the user to be really technical Savvy to really understand that simulations only tell uh what a good day look like and in a bad day it can be a lot of variants on how bad it could how different kinds of weird awkward situation it could occurred in so yeah that's just my yeah two cents yeah but definitely

so it's all the new X problem around making sure users understand that this is just for simulation and different things can happen on chain is definitely a challenge we need to solve at the moment we don't have a way of actually submitting the the batch um and so that's what all you can do is simulate and you can simulate them all and then you can go back through and do them all again we're working on hopefully making it so you can actually submit a batch but again that's a little further off for us but yeah you are correct that anyone who does use this multi-call definitely needs to be aware that this is just simulation off chain very useful certain things but not everything thank you it's basic stuff it's called but just

way more powerful than that is yep great thank you Micah anybody else have um demos cool wallet stuff they've been working on great then I guess we can call it here thanks everybody for coming out and we'll see you all in about a month see yep nope oh yeah does jitsy not have little reactions so I can wave goodbye

there's racer yeah it does yeah if you do the raise your hand thing it has other ones oh I see yeah there you go