`_validateSignature` can be replaid on multiple chains

[hats-bug-reporter[bot]]

Github username: @0x3b33 Twitter username: -- Submission hash (on-chain): 0x0dafba3765cbcd539115fa33c3449294d1fb96d19eb17b92db269a998a30f028 Severity: high

Description: Description\ AtomWallet's _validateSignature internal function doesn't verify chainId consistency. This means if the same AtomWallet exists on two chains, any signature sent to validateUserOp would be replayable on the second chain.

This is extremely dangerous as any user can copy the transaction and send it to the AtomWallet on the other chain.

Example:\

1. Alice has 2 AtomWallets on 2 different chains.
2. Alice gives Bob permission to send 1 ETH to is address.
3. Bob executes the transaction and copies the permission to execute it on the other chain.
4. Bob withdraws 2 ETH from Alice.

Attachments\ Implement a check inside _validateSignature for chainId. For example, chainId can be included together with the string and userOpHash.

[mihailo-maksa]

We recognize the potential concern raised, but the issue's severity is mitigated by several factors:

1. Single-Chain Deployment: Our contracts are currently deployed on a single chain. As such, the risk of replay attacks across multiple chains does not exist in our current operational context.
2. ChainId Validation by EntryPoint: The BaseAccount contract from the @account-abstraction library already incorporates chainId validation as part of its design. This ensures that transactions are valid only on the intended chain, preventing cross-chain replay attacks.
3. Planned Research: We will conduct further research to confirm the effectiveness of chainId validation and to explore the necessity of validUntil and validAfter fields. However, our initial assessment indicates that the chainId is indeed accounted for by the EntryPoint.
4. Future Considerations: Should we decide to deploy our contracts on multiple chains in the future, we will ensure that appropriate chainId validation mechanisms are in place.

In conclusion, while the concern is valid in a multi-chain context, it does not currently apply to our single-chain deployment. The EntryPoint contract handles chainId validation, and our implementation adheres to the standard. Therefore, the issue is not a high-severity vulnerability in our current setup, is not of a concern because of the role that EntryPoint plays. We consider the issue to be invalid, and it is also lacking a valid revised code file and PoC.