EIP-7702: Set EOA account code

[nathanglb]

This is a great find, and highlights why some of us have been concerned about rushing 7702 to production.

[nathanglb]

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.

limitbreakinc/creator-token-standards/blob/main/src/utils/CreatorTokenTransferValidator.sol#L1744-L1882

[matt]

@frangio

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.

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.

@nathanglb

and highlights why some of us have been concerned about rushing 7702 to production.

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.

[nathanglb]

What about the example protocol we have in production that I referred to in this post?

EIP-7702: Set EOA account code for one transaction

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 underlyin…

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.

[0xth0mas]

@matt

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.

Do you have any links to research that has been done into how EXTCODEHASH is being used in smart contracts and analysis of the potential security implications for ones that are using it? A GitHub search finding even one example likely means there are more out there in the wild.

[mitche50]

7702 is absolutely being rushed to production. The EIP was written in 30 minutes in May and is slated for the next production release.

Defaulting to “I’m open if you can provide a practical example” is not really a legitimate reply. Changing the functionality of an ecosystem which has billions of dollars of funds reliant on immutable code should warrant a deep testing period, public test nets, prepared wallet integration and testing, public knowledge documentation and more. Application developers are barely aware of the implications of this, and previously deployed protocols will need sufficient time to migrate or upgrade code.

This can’t be a “bury our head in the sand and hope nothing bad happens” moment.

[nathanglb]

I think a reasonable suggestion is to add 2 opcodes. One opcode that is cheap (2 or 3 gas) to check if 7702 is in play. The other would be an delegatedextcodehash op code that is the code hash that is attached. Leave the original extcodehash as is.

[WOK]

With an impending implementation date of “Early 2025,” when can we expect a test environment? This is a change that has the potential to affect all network participants in a way that is more dramatic than most previous upgrades. The end of 2024 is quickly approaching…

[frangio]

@matt

I’m open if there are more practical examples, but it doesn’t seem like a major issue.

It’s not major, but if there’s a simple fix I think it’s worth considering.

The basic fix I have in mind is that EXTCODE* opcodes shouldn’t follow delegations, the delegation logic would be used in *CALL opcodes only. I’m undecided whether EXTCODE* opcodes should operate on the full delegation designator, or if they should behave like EOF contracts and act as if the code was just 0xEF01. In either case this would make delegated accounts a lot more like proxies so should be less surprising.

[abcoathup]

There is a public testnet for Pectra planned to run during Devcon. This will be a great time to test, experiment and even break functionality if you can.

[rdvorkin]

Did some gas cost analysis comparing sweeping under 7702 to 3074. You can check out the findings here:
https://hackmd.io/3PsQucEESHSSzXaWNrnDOg

TLDR: Sweeping is 3x more expensive with 7702 than 3074, which impacts end users.

While we’ve moved beyond 3074, I wanted to raise awareness about the cost implications of 7702, which haven’t been discussed much. Is there any potential for cost improvements in this use case, particularly when delegating multiple EOAs to a single contract in a single transaction? Thoughts are welcome.

[matt]

Cheap sweeping isn’t a goal of 7702.

[chfast]

You could have used the delegation designator prefix of 0xEF ++ MAGIC, i.e. EF05.

[peersky]

Point is that if before account could selfdestruct, and leave any assets locked in there hanging, hence worst of what attacker may attempt to do today is cause harm to the protocol by draining it, yet it will not be able to withdraw funds.

Now with this EIP, it’s EOA, which is able to control these assets, and hence it creates legitimate attack vector that pays back to attacker.

I also assume, that’s obvious that there are numerous assertions that will become faulty via isContract, like this ? Such checks, if checking for isContract==true, will result fault assertions that account cannot send auxiliary transaction while it can.

[nathanglb]

This one might not be as big of a deal, because OZ’s isContract function already had some noteable workarounds like contracts in construction, counterfactual addresses, etc and thus was already unreliable.

[dror]

I think that eip7702 contract behaves more like an erc1967 than like a real deployed code.
Just like a proxy code, no one expect to rely on the code of the proxy itself, as the owner might change it.
Eip7702 contract is a low level modifiable proxy, and should not attempt to hide it.
That why it should be visible to the EXTCODE* opcodes, and they should use its real 0xEF… code, not the delegated contract.

[hiddenintheworld]

1. Flag Triggering:

   • How does the flag work to make an EOA a permanent smart contract wallet?
   • Is the flag set during the transaction? Can the same contract_code be reused, or is it one-time(will be dumped afterwards)?
   • Will users need to sign off on this change explicitly, or could it happen automatically?
     @vbuterin @SamWilsn

2. Expensive Transactions:

   • Complex contract_code or initcode might need a lot of gas, especially with things like signature checks or calling external contracts.
   • Could this make transactions too expensive for users with less ETH? Should there be limits on how complicated the code can be to keep costs down?
     @dror

3. Interaction with ERC-4337:

   • What happens if an EOA temporarily becomes a contract wallet and interacts with EntryPoint contracts in ERC-4337?
   • If contract_code or initcode reverts in the middle of a transaction, could this cause invalid UserOperations (UserOps)?
   • Could this lead to issues with how ERC-4337 handles these failures, maybe even causing a denial-of-service (DoS) attack on the AA mempool?
     @Ivshti @0xkvn

4. Unintended Behavior in UserOps:

   • Reverts in contract_code or initcode could cause a bunch of UserOps to fail, especially if the code checks something like the block timestamp and cancels the operation.
   • Could this lead to a mass invalidation of UserOps, clogging the AA mempool and causing DoS-like behavior?
   • Also, what about cross-chain replay attacks if the contract_code is chain-agnostic and can be exploited across different networks?
   • The only way it works is to ask each bundler to inspect initcode which is extremely inefficient, so we must find a way to work around this.
     @yoavw

[Ivshti]

The basic fix I have in mind is that EXTCODE* opcodes shouldn’t follow delegations, the delegation logic would be used in *CALL opcodes only.

This (EXTCODE* not following delegations) will break EIP-1271/EIP-6492 signatures and has very few upsides.

[Ivshti]

7702 is absolutely being rushed to production. The EIP was written in 30 minutes in May and is slated for the next production release.

That’s absolutely not what happened, there were multiple iterations, discussions and etc. Most of the concerns and points I’m seeing here in this thread have already been discussed, and most (if not all) of the compromises have been very carefully and deliberately weighted.

As for the attack vector itself, authorizing code hashes sounds like a risky idea from a security perspective in the first place. Analyzing for real-world examples is absolutely the right thing to do - if we bogged down in hypotheticals then it would be even harder to get this to production.

[matt]

@Ivshti

This (EXTCODE* not following delegations) will break EIP-1271/EIP-6492 signatures and has very few upsides.

Could elaborate on this? AFAIK those EIPs only check for existence of code? e.g. proxies work with them today.