Update ERC-6900: add security considerations (#9)

Merged by EIP-Bot.

ERCS/erc-6900.md

@@ -550,7 +550,13 @@ See `https://github.com/erc6900/reference-implementation`
 
 ## Security Considerations
 
-Needs discussion.
+As much as the modular smart contract accounts themselves, installed plugins are trusted components, as a modular smart contract account can be almost arbitrarily configured through installed plugins. A malicious plugin could add always reverting hooks to native function selectors, bricking the account, as well as add function selectors that end up draining the funds of the account. Users should therefore be very careful in what plugins to add to their account.
+
+Users should therefore perform careful due diligence before installing a plugin and should be mindful of the fact that plugins are potentially dangerous. The plugin's manifest can give users an understanding of the domain of the plugin, i.e., the requested permissions to install certain validation functions and/or hooks on certain execution selectors. Generally, plugins that include native function selectors in their domain, e.g., plugins that add a validation hook to the native `uninstallPlugin()` function, can potentially introduce significantly more harm than plugins that simply add validation hooks to function selectors that the plugin itself is adding to the account.
+
+Plugins can also add validation hooks to function selectors installed by other plugins. While usually, such a plugin would, e.g., add additional pre-validation hooks, it can also cause the previously installed plugin to be executed in an unintended context. For example, if a plugin were to only be intended to operate in the user operation context, its plugin manifest might only define user operation validation functions. However, another plugin might add a passing runtime validation function to that function selector, causing, for example, a session key plugin to suddenly be executed in a runtime validation context, circumventing all the parameter-validation that would have happened during user operation validation and granting unrestricted access to all session keys. Therefore, it is strongly recommended to always add reverting validation hooks to the context the plugin is not intended to be executed in. This recommendation may change in the next iteration of the standard.    
+
+It is worth mentioning that execution hooks have no awareness of other execution hooks being performed in the same function selector execution setting. Since execution hooks can perform state changes, this reveals an important security consideration: An execution hook can only assure that at the time of its own execution, certain conditions are met, but this can not be generalized to the entire pre-execution context of potentially multiple pre-execution hooks. For example, a pre-execution hook cannot be assured that the storage it performed validation upon does not get further updated in subsequent pre-execution hooks. Even an associated post-execution hook potentially repeating the validation cannot assure that the storage remains unmodified because a prior post-execution hook may have reset the state. As long as the requirements checked by a plugin as part of an execution hook are only modifiable by the plugin itself, this can be considered safe.
 
 ## Copyright