Alchemy Modular Account

Plugins can register hooks to offer custom functionality during various stages of a user operation or runtime transaction. However, a malicious plugin can abuse this by introducing hooks that consistently revert, preventing the user from uninstalling the plugin or upgrading the account. As arbitrary selectors can be specified, this could completely brick the account. This issue outlines the most significant impact of the dangers of the plugin trust model. Other cases are covered in MSCA-10.

Plugins can define pre- or post-execution hooks to a specific execution function, which allows them to perform additional validations or modify states before or after the execution function call. However, when a plugin receives a call to its pre-execution hook, it should not assume that the state at the time of the pre-hook call will remain unchanged when the execution function is called. This is because the MSCA implementation allows overlapping hooks, so multiple pre-hooks can be executed after the current pre-hook but before the execution function call. Furthermore, The execution order of the hooks cannot be enforced by the plugins and depends on the account's internal state. Therefore, validation in a pre-hook based on the current state may no longer be valid if the state being checked is changed by another pre-hook before the execution function call. For example, the `SessionKeyPermissionsPlugin` defines a pre-execution hook, which invokes the `_updateLimitsPreExec()` function to update the ERC-20 token spend limits of a session key based on the `transfer()` or `approve()` value. If the call is `approve()`, this function relies on the current allowance to the spender to calculate the increase in the amount spent. However, such a calculation can be erroneous as it assumes no allowance change will occur after the current pre-hook call. A similar issue may exist in post-hooks and validation hooks as well. For example, the state at the time of a post-hook call may not be the exact state after the execution function is executed since there may be other post-hooks in between and change the state.

The MSCA's security fully relies on a proper configuration of trusted plugins. Therefore, end users should exercise extreme caution around installing and even uninstalling plugins. Below is a non-exhaustive list of areas of concern that are based on plugin trust assumptions. 1. The MSCA does not provide any native protection of function selectors (though it natively also can not properly spend native assets and tokens). So uninstalling plugins could incorrectly loosen access around certain functionality, for example, if the `MultiOwnerPlugin` were to be uninstalled without any replacement protecting the same selectors to the same degree. 2. A malicious plugin can block access to arbitrary selectors, as outlined in MSCA-5. 3. Furthermore, plugins should always be assured to not be upgradeable, or else unexpected functionality could be introduced via registered validation and hooks. 4. An installation of a malicious or even faulty plugin could cause arbitrary consequences, including loss of funds. 5. Installing plugins that add execution hooks to selectors increases the chances of a validation passing, but reverting user operation execution. While this is a desired design aspect of execution hooks, the Entry Point contract will assure that a Bundler is reimbursed, either by a paymaster or the paying account, for validated user operation, regardless of the success of the execution. Therefore, plugins adding execution hooks to selectors add a level of risk to the account. 6. Uninstalling a plugin providing a certain selector and installing another one using the same selector can cause unforeseen behavior, as other plugins from the prior installation might still have hooks and validation associated with the replaced selector 7. To upgrade the MSCA, one would need to call `upgradeToAndCall()`, and it is up to the user to either uninstall or not the plugins, depending on the severity of the upgrade. So, it is possible not to uninstall plugins and have such an upgrade that either adds functions or changes the function selectors on existing functions. This would lead to an uncertain state, as a malicious plugin can pre-register a hook for a non-existing selector that would be added at an upgrade and hence hijack execution.

ZK-based EVM, such as zkSync or Scroll, implement their own version of Ethereum Virtual Machine and are EVM compatible but not to the full extent. There are some opcodes that are not supported or some opcodes that behave differently from what happens on the mainnet. If you plan to deploy on a ZK-based chain, it is important to take these into account, particularly the following opcodes in the case of **[zkSync](https://era.zksync.io/docs/reference/architecture/differences-with-ethereum.html)**: 1. `CREATE2` 1. > To guarantee that `create`/`create2` functions operate correctly, the compiler must be aware of the bytecode of the deployed contract in advance 2. `MSTORE, MLOAD` 1. > Unlike EVM, where the memory growth is in words, on zkEVM, the memory growth is counted in bytes. For example, if you write `mstore(100, 0)`, the `msize` on zkEVM will be `132`, but on the EVM, it will be `160`.

In the `MultiOwnerPlugin`, an MCSA can have multiple owners that each have equal weighting in terms of execution power. This brings advantages of multiple users or entities sharing the account but also complexities such as the one described below. Due to the nature of equal weighting, in the case where one owner's account is compromised or turns malicious, another benign user would attempt to remove the malicious one from the owner list via `updateOwners()`. Theoretically, that would work, but due to the blockchain nature, the malicious entity can monitor the memory pool and front-run the `updateOwners()` with `updateOwners()` of their own, removing the benign owner, hence causing their removal to revert due to lack of permissions. This leads to a race condition style issue in the plugin.

The `AssociatedLinkedListSetLib` hashes a composite key to store and retrieve items linked to an account. Given the frequency of this operation, the library employs the `_allocateTempKeyBuffer()` method to create a memory buffer once and only update it when necessary, all in assembly. However, the `_allocateTempKeyBuffer()` function does not update the free-memory pointer, meaning Solidity remains unaware of any memory changes. This could result in the buffer being mistakenly overwritten. Although the current code seems to avoid erroneous overwriting, the design is quite brittle. Even minor modifications could disrupt memory, potentially breaking the code.

According to the code documentation, the `PluginMetadata` struct contains view information intended for front-end clients. However, it is critical to note that this data is not validated. Plugin authors can input any `name`, `version`, `author`, and `permissionDescriptors` they choose. Depending on the usage of this information, malicious developers could potentially mislead MSCA users into installing harmful plugins that resemble legitimate ones.

During installation, the dependencies of the being installed plugin are checked against the `dependencyInterfaceIds` in the plugin's manifest. The MSCA ensures that each dependency contract supports the given interface via ERC-165. This approach provides a basic validation of the contracts. However, there are several existing limitations: 1. If the interface of a dependency is provided as `IPlugin` (as in the session key plugins), we can only ensure the dependency contract is a plugin without knowing what type of plugin it is (e.g., `IMultiOwnerPlugin`). 1. The MSCA does not validate that the provided `functionID` is valid for the given dependency. 1. Two plugins can implement the same plugin interface while being different on the function ID order or implementation.

The plugins rely heavily on the `AssociatedLinkedListSet` or `PluginStorageLib` libraries to calculate the storage slots associated with an MSCA. A slot is calculated as `keccak256(address || batchIndex || input1 || input2)`, while `input2` is optional. Therefore, the data appended to the `address` is 64 or 96 bytes long. However, according to the latest ERC-4337 specification at the time of writing (commit `8dd085d`), the document does not explicitly specify the length of the appended data can or should be. It is mentioned that slots of type `keccak256(A || X) + n` are to cover mappings with the wallet address as the key, thereby implying that the acceptable range of `X` should at least include 32. ([reference](https://eips.ethereum.org/EIPS/eip-4337#storage-associated-with-an-address)) The [draft EIP-7562](https://github.com/ethereum/ERCs/pull/105) specifies that the appended data should be 32 bytes long (see point 5). On the other hand, the Infinitism bundler allows the data lengths between `[0, 480]` bytes. ([reference](https://github.com/eth-infinitism/bundler/blob/ba78f2067e33df399bb7d34a9d1f972834d23c80/packages/validation-manager/src/BundlerCollectorTracer.ts#L324-L327))

If a session key's access control is configured to interact with an ERC-20 token contract, it could consume the MSCA's entire balance and allowances if a spending limit is not also specified along with the access. This is because contract calls are only checked for token transfers and allowances if `tokenContractData.isERC20WithSpendLimit` has specifically been set to `true`, which is only set if the spending limit is explicitly set to a value smaller than `type(uint256).max`. Not performing this explicit update, but enabling the session key to interact with the contract, will therefore act as an unlimited spend limit for that token.