ERC-6492 Security Risks and Safe Implementations | Chris Smith - Spearbit

hello everyone welcome to uh the afternoon Edition at bid Squad stage in the bidle hub uh my name is Jane harell I will be your MC for the rest of the evening and uh first up we have Chris Smith from spearit and he's going to be talking about ERC 6492 new security risks and safe implementations how is everyone doing let me see if I can get this to be full screen here or as close to it as possible okay excellent um so as Jane said my name is Chris Smith I am a security researcher with Cantina spear bit I'm one of their fellows um in that role I get to see a lot of different code patterns a lot of different um projects and one of the interesting security uh considerations that I came across was ERC 6492 uh so I thought I would talk about uh what that is and some of the security considerations that go into it um I'm going to use a hypothetical uh smart contract system a Dap here for this to make it hopefully a little bit simpler uh so that the uh actual system doesn't get in the way uh and then we're going to walk through what uh ERC 6492 is and uh some of the attack and potential M uh M mitigations with it so first uh let's talk about our uh hypothetical system here see if I can make my speaker notes a little bit bigger for myself there we go okay so very simple system we're going to have a permissioned uh dap contract that's going to interact with a user's address EA or smart contract proxy um and that proxy can be launched via a factory uh when I say permission smart contract the user is going to Grant this dap some sort of permission on their wallet to transfer funds or to do some admin work for them um this is going to be a common pattern that you see in a lot of daps where they're having the user authorize their uh smart contract or authorize the DAP to do something on their behalf um it's a key part of account abstraction because you try try to take submitting those transactions away from the user let someone else handle it's a little bit easier user experience um and uh a little easier for the users um as I said there's going to be a proxy Factory this is just going to deploy the users smart contract smart contract proxy uh the important thing with the factory for this is that it's deterministic so you can predict what the next smart contract address is that's going to come out of there um and as I said the user is going to give the DAP permission to do something on their behalf so to understand what ERC 6492 is doing within this system um you first have to understand what ERC 1271 does so as you saw in the smart contract system that we're dealing with here we have either an EA or a smart contract proxy for the user EAS can provide signatures so that they can permit the DAP to do something smart contracts can't necessarily do that where they provide a signature for permit function that's what 1271 solves so it implements a standardized way for smart contracts to provide and validate signed messages uh using this is valid signature function now protocols can treat smart contracts or EAS in the same way when it comes to permit or authorization um this helps and opens up opens up possibilities with account abstraction and smart wallets as we'll see okay 6492 Builds on top of 1271 so the problem with the problem that 6492 is trying to solve is as I said the user is deploying their proxy or the proxy will be deployed using a factory and that may not yet be deployed so now we're dealing with a multi-chain environment in blockchain perhaps you have your smart contract wallet deployed on mainnet but you don't have it deployed on the L2 the DAP goes across both systems and you want to be able to provide that uh same experience to your user same signature uh authorization permit to the user but their contract isn't deployed on the L2 yet you want to make it an easy process for them you don't want them to have to deploy their contract first before they start doing things with the DAP some of these daps require you to sign something just to sign in and use the DAP um so you don't want to make the user deploy the contract that they don't necessarily have yet on the chain in order to do that that's where 6492 tries to come in um it allows you to have signature permission on deferred deployment contract or deferred contract setup so the signature when validating the signature 6492 describes the flow for how you can deploy the contract using the proxy Factory or you can make a call to the user's contract if it's already deployed to set up some sort of authorization set up a signer set up a user um do a approval something like that 6492 specifies that in order to do this you're going to wrap your 1271 signature in a um a a new way you're going to add either a address for the create 2 Factory and the call data for that or a prepare two address and the call data for that and then encode that with the 1271 signature and wrap both of those things or actually append the 6492 magic bytes code on the end of that signature and that's how we'll tell that we're dealing with 6492 rather than 1271 all right so now I'm I want to dive into um an implementation I'm going to use the soady implementation here here from their signature Checker lib um this is the I love the function name is valid ERC 694 sorry 6492 signature now allow side effects function in their signature Checker lib um very important note here this is an older version of the soady library they have updated this this is taken from version 00236 the current version is 019 so they have made a lot of changes to the Sol lady uh implementation I'm using this because it's the one that I came across in the audit and I think it was a little bit simpler to show how 6492 flow Works within the signature Checker lib so let's dive in and look at this code um we'll take it bit by bit the first bit here is this internal assembly function is uh call is valid signature this isn't something we need to dive into too much it's just the abstraction of how we're going to do the 1271 signature check throughout the rest of the code so the first substantive piece that the S implement ation is going to do for us is we're going to check to see if we're dealing with 1271 or if we're dealing with 694 uh 6492 sorry a lot of EIP numbers they get jumbled so the first line here the if statement is checking whether or not that magic code this 0x 6492 6492 6492 on and on and on is present at the end of the signature that we received if it's not so if that value is zero then we're just doing a regular 1271 validation and we can call the contract signer with the signature per normal using that function that we just looked at however if we do find the 6492 there we need to do some other things to the signature before we can proceed so the first thing we're going to do is we're going to find the location of the address this is either going to be that um proxy Factory address or the prepare 2 address so that's what goes into the O slot here is the starting location of that address the D is going to be the call data that we're going to use when we make that call regardless of where we're going with it our if statement here is checking whether or not the signer address has code at it that tells us whether or not the smart contract has been deployed if it hasn't been deployed yet then per 6492 uh specifications we need to go try to deploy that smart contract before we validate the signature so if there's a zero code size at the signer address then we're going to call the O address which we assume is the proxy Factory with our call data check the return if the return is zero we assume that call failed and we're going to break out of the whole function is valid signature is currently false so if we break out at this point we're going to tell whatever uh application the the DAP in this case called this that we don't have a valid function signature we couldn't deploy the code basically and that uh smart contract is probably going to stop doing whatever hopefully it's going to stop doing whatever it did and throw some sort of revert if that call succeeds then that won't be zero and we get to proceed to the next piece so we've checked that we have a 6492 implementation we've checked that the contract is there either it was there already or we deployed it and it's successfully there now um we know that we're dealing with a 6492 wrapper situation we've already grabbed o we've already grabbed D now we need to get the actual signature that we're going to check so that's what the first line does and then we're going to just call the the signer and say hey is this a valid signature and store that value if it's not a valid signature then we want to try that prepare two call and that prepare with the prepare two data which is what this if call does again it's calling the address o with call data D we don't check the return here because we're going to go check this the signature next and we're going to overwrite our previous uh is valid signature so at this point we kind of see how the 6492 flow is working either we do 1271 signature per normal or if the contract doesn't exist we're going to try to deploy it or if it does exist or we've successfully deployed it we're going to check the signature per 127 if that signature fails we're going to make another call to that o address and then recheck the signature after that last recheck we take whatever the result is and move on return this back to the whatever called the library some important security considerations about how this is constructed as you saw when I was talking about the ERC uh 692 specification this the prepared two data or the factory data is not part of the actual signature we're not checking the users's signer that they signed that data and verifying that data this is just arbitrary data that's wrapped around our 1271 signature that means that if your dap is using thirdparty permissionless Keepers that are pulling these signatures for your users from some sort of M poool or something like that they can pull one knock this data off or add their own data around a 1271 signature and your dap won't know anything about that so the prepared to address the Factory address and the call data that go with these things are effectively arbitrary addresses and arbitrary call data now this is very very important because we've seen kind of the flow of how 6492 works so let's go back to our system remember the user is setting up some sort of permission or already has set up some sort of permission between the DAP and their smart wallet that's holding some sort of value presumably or potentially um they're providing a signature that someone else is delivering to the DAP their contract or their EA is going to check that signature many of these proxies have some sort of batch function or multicol function to help with the user experience of the of using the wallet or for dap so that they can do multiple things in one transaction this is actually a feature for them it increases security if you want to provide a limited approval and do a transfer in one transaction the multi-call function in a in a user's proxy is going to handle that for you so a lot of these smart contracts have that feature and you'll see why it's important to point that out as that comes into play later again the factory can deploy the contracts in a deterministic way um this is just rehashing the system that we described earlier all right so let's look at the two attacks for this so for the first one we're going to make a couple of assumptions in this case the user's proxy is already deployed and has the DAP set up with permissions the user proxy has some sort of State in it that can be changed by the DAP that will make the signature initially invalid and then later be valid so we have some sort of State toggle let's say like if you're adding a new signer maybe you have have a signature that is for that new signer your dap has permission to add that signer to this the user's smart wallet um that would be a case where obviously the signature is not going to work the first time the signer is not added the D makes a call hey the signer is there now the signature works so that's what I mean by that do that toggle so the attack here is we have a 6492 wrapper we're not going to go through the 1271 flow our signer contract the user's wallet is already deployed so we don't need to with the proxy Factory we can ignore that when a signature valid is called we're going to get false because in the hypothetical the signer is not set up or whatever about the user's wallet that state isn't set up in such a way that the signature is going to be valid so now we take so we have a deployed wallet and a failed signature in that 6492 flow that means we're going to make a call to prepare 2 with our prepare call data the attacker has replaced or has put in the their own call data for the prepared data that is a multi call for that proxy the first thing they're going to do and remember the the DAP has permission on the on the user's proxy here so the first thing they're going to do is drain all the funds they're going to send the the money someplace that they want it to be because that's the point of the attacker the next thing they're going to do is make a call within that proxy such that the state changes so that the signature is valid so in 6492 signature is invalid make an arbitrary call to an arbitrary address check the signature again hey it's valid transaction goes forward no revert user doesn't have any money and the attacker has it all second attack doesn't require that state where the user's wallet has a batch function and it doesn't require the state where the DAP can toggle that signature validity between a false to a true State this one again assumes that the user's wallet has been deployed and the uh user has set up the permissions for the DAP so this is you know after a user has used the DAP for a little bit everything's hunky dory an attacker comes along takes that uh sorry finds out the attacker sorry the the victim's address they don't even need a signature for the victim in this case they're going to construct their own 6492 um signature with their own malicious signer so they put the 6492 wrapper around their signat their 1271 signature their contract their signer is already deployed we call is valid signature on their contract which says hey this isn't a valid signature because of whatever code the malicious person has written into that contract and then the call data is going to um the sorry the DAP is going to use the prepare 2 and the call data to call the users wallet transfer funds to the attacker signer which is probably using a balance two check to make that Boolean toggle of is valid signature is not valid signature and now the malicious signer is going to say hey that signature looks good because I've already got the funds and the attacker can steal and drain the wallet of any user using this system um without them even having to use 6492 patterns they can just take their own 1271 signature so these attacks have a couple of things in common um the key one is that the permissioned contract the DAP is the one also doing the signature verification um and the other big thing which I've already pointed out is that the Factory address and the prepare two addresses are arbitrary and the call data that they're using are arbitrary so you can put anything in there that you would like as an attacker we can um make this system more secure by inserting a new contract a signature Checker contract that is going to be the one that makes the call to the proxies or to the factory and handles the 6492 flow so now the DAP is no longer the message sender even if there's a batch function even if there's a multi-call transaction um the message sender that's making the arbitrary calls in the 6492 flow which are the ones that we're worried about is now this unper permissioned signature Checker contract so this would alleviate that um those two attack vectors all right um so like I said I'm a fellow with Cantina spear bit uh they do provide security reviews code competitions bug bounties Cantina doxyz is uh how you would find out more about those um I'm going to post these on my Twitter account at am Chris Smith and um I've got probably about a minute 45 if there's any questions I can try repeating them or we can wrap up early all right I think that does it then thank you