Another phishing vector that doesn’t involve protocols at all:
Drainer phishes as many signatures as possible to attach unverified, malicious code to their EOA. For the sake of argument, say they are able to harvest hundreds of such approvals because nobody checks to see if the attached code is verified. And even if it is verified, nobody reads the code anyway.
Drainer executs a drain transaction on a smart contract they have deployed. The 7702 special tx includes dozens of phished victims at once.
drain loops over the supplied victim addresses, calling drainAssets on the malicious code that has been attached to victims’ accounts. It searches for valuable assets like ETH/WETH/USDC/etc and valuable NFTs, calling transfer to the attacker on everything it can find that is considered valuable.
The only thing that can prevent this is tokens that implement Limit Break’s ERC20-C/ERC721-C/ERC1155-C with security levels set to block OTC.
Look, the people that get phished for their entire net worth are just going to have to take one for the team as this new technology advances and appropriate safeguards are put in place after thorough post-mortem analysis.
There are already many phishing vectors. Users should know what they are signing and that’s the wallet’s responsibility. These signatures don’t resemble other signatures so older wallet software won’t be prone to this unless they were already prone to much worse attacks (such as eth_sign: What is 'eth sign' and why is it a risk? | MetaMask Help Center 🦊♥️).
Wallet security is hard and at first it will be hard to support this feature safely. However, the feature is good and so technology will improve to support it.
Most of the current phishing vectors revolve around signing EIP712 signatures that are semi-readable, rely on open approvals, don’t risk native funds, and are generally easy to simulate the potential impact of signing.
This EIP has the potential to drain all valuable assets, including native funds, with a far less readable signature that is harder to simulate. I would not be surprised to see wallets take a highly centralized approach to what contracts are allowed to be signed. It will be a step backward for security and decentralization while being pushed towards the finish line at a remarkable pace.
If there’s a significant enough security incident will we end up with ETCV2?
I completely agree - that’s why I love EOAs and self-sovereign wallets. Account Abstraction is about onboarding people that don’t understand crypto/wallets at all. You can’t expect them to know/understand what they are signing if the only way to onboard them is to hide the Web3 wallet from them altogether.
If you phish a signature for a delegate authorization, all bets are off. It has root. You don’t need clever protocol shenanigans at that point.
You could, of course, also have just phished a signature for a transaction which called transfer directly; the only difference here is that it lets you batch TXes, which is frankly a feature and not a bug. I’m looking forward to there being a simple and cheap way to sweep all assets from an address with a compromised key to a new one.
Do I understand correct, that in result of this eip:
solidity address(EOA).codehash will return one-time code hash value during the transaction?
Was there analysis of consequences for existing address.codehash users (github finds some)?
There will be no means to identify within EVM runtime that addresses bytecode is temporarly set?
Im guessing answer is in these lines
The delegation designation uses the banned opcode 0xef from EIP-3541 to designate the code has a special purpose. This designator requires all code retrieving operations to follow the address pointer to fill the account’s observable code. The following instructions are impacted: EXTCODESIZE, EXTCODECOPY, EXTCODEHASH, CALL, CALLCODE, STATICCALL, DELEGATECALL.
But perhaps someone can translate to simpler language? Does this formulation meaning is that external contracts will observe EOA as an EOA?
Also thinking if moving ERC7744 to eip could allow one-time deployers to specify codehash instead of sending full bytecode as @wjmelements suggests?
Their public method originate internally calls _callCustody that reverts based on user-provided custodian field, which is being checked via extcodehash.
With 7702, adversary could temporary delegate to make it look like he is valid custodian, inside originate the transferSpentItems method would send assets to adversaries EOA.
Basically contracts could so far assume that codehash would be a reliable indicator of the behavior of an account. Unless the behavior was that of a proxy it could be assumed to be immutable. EIP-7702 changes that by introducing “invisible proxies”.
I think this is a very legitimate security concern.
I don’t really understand this point, can you expand on the issue? IMO until cancun, it was possible to selfdestruct an account and deploy alternative code. So an account having different code isn’t really a new problem.
I think the difference is that for that to happen the account had to have selfdestruct or delegatecall in its code, so observing codehash (with known preimage) you would know the code could change. Now the code change can be a “surprise” because there is no indicator.
This would be solved making EXTCODE* not follow delegations.
Right, but what exactly is an example where a “surprise” code change would cause harm? In general you either fully trust the code you’re calling into or you don’t trust it at all and must be defensive.
An example would be a contract that transfers tokens to an account only if its codehash is the known codehash of a timelock, assuming the rules of the timelock will be respected. With EIP-7702 an EOA would be able to masquerade as a timelock and bypass the restrictions.
In the example above you trusted the known code, and you reasoned you could trust the account on the basis of its codehash.
This is a little contrived. In practice the contract would probably deploy the timelocks itself rather than checking the codehash, or it would require a CREATE2 address and validate the entire creation code and parameters.
I searched superficially and wasn’t able to find real world examples that would be vulnerable to this kind of attack. But it doesn’t sound that far-fetched to me.
Creator Token Standards offers a system to add a validator which can introduce logic gates into transfers, enabling many new use cases. For flexibility, the reference validator implementation allows creators to whitelist operator code hashes that they trust that are allowed to receive tokens or be operators on tokens.
I don’t think it is that far-fetched to think that masquerading as a whitelisted operator or receiver code hash could lead to a security incident (depending on what the underlying code does). This protocol is very generic though, so I would say the severity of masquerading as a whitelisted code hash could range from no impact to critical impact.
Fortunately, there is no “Authorizer Codehash” list in this current reference implementation, but had there been an EOA could masquerade as an authorizer and possibly do some damage as well.
Yeah this was is also my initial reaction. I’m open if there are more practical examples, but it doesn’t seem like a major issue. And if you need to be certain about some code, just deploy it yourself.
7702 definitely isn’t being rushed to production . 7702 is going to slightly change how protocol designers need to think about their protocols. It’s possible to come up with contrived protocols that have issues, but there are ways to work around.
What about the example protocol we have in production that I referred to in this post?
It’s not actually contrived. We added operator code hash whitelisting at the request of token creators, and depending on what gets whitelisted, I could see the possibility of a bad impact.
. 7702 is going to slightly change how protocol designers need to think about their protocols. It’s possible to come up with contrived protocols that have issues, but there are ways to work around.