Account Abstraction, Analysed: Security Analysis

Table of Links

• Abstract & Introduction
• Ethereum Accounts
• Account Abstraction
• Security Analysis
• Further Discussions
• Conclusion & References

IV. SECURITY ANALYSIS

We explore the potential security issues that may exist in new account formats after its update. We recall a series of account threats and related smart contract risks and develop a framework to evaluate potential risks in account abstraction.

Focused scope. Conventional analyses of Ethereum often partition it into four distinct layers (e.g., [20]): the application layer (including accounts, smart contracts, and EVM), the data layer (including transactions, blocks, and events), the consensus layer (involving PoX mechanisms and incentives), and the network layer (comprising node discovery, message propagation, and verification). Given the central theme of this endeavor around accounts, we deliberately narrow our purview to the application layer, exploring the potential vulnerabilities targeting accounts, smart contracts, and related solidity language. Additionally, our coverage extends to certain elements within the transaction and block layers.

Framework design (Tab.III). Inspired by a series of elegant investigations [20]–[27], we distill a succinct overview of vulnerabilities present within the current Ethereum application layer. These vulnerabilities can be broadly attributed to three factors: design pitfalls, vulnerabilities intrinsic to the Solidity programming language, and errors stemming from contract programming. Within each of these categories, we identify and elaborate upon sub-vulnerabilities (Vulnerability) that manifest across diverse functions and processes (CauseFmWhere). Our discussion then delves into the potential of account abstraction to alleviate these vulnerabilities. We examine the feasibility of employing account abstraction to mitigate these issues and explore strategies for implementation that could effectively address these concerns (byWhichFunc).

Analyses. Our discussions are categorized into two facets, contingent upon the effectiveness of AA updates.

✓ Transaction disorder. This vulnerability centers around a concurrency issue where the blockchain’s future state is contingent upon the sequence of transaction execution, a process influenced by miners who group transactions into blocks based on incentives. The design of AA effectively mitigates this problem by employing bundlers to manage and submit transactions. Unlike miners or validators, bundlers have a limited scope of impacting transaction orders, as they handle a relatively small number of transactions.

✓ Timestamp manipulation. This vulnerability happens when a contract utilizes block.timestamp in crucial operations or as a means of generating randomness. It can be exploited by a malicious miner who has the capability to manipulate the value of block.timestamp (evidenced by [28]). The introduction of account abstraction helps address this concern, as AA reduces reliance on block.timestamp and shifts focus to bundlers, which are better suited for managing transactions and ensuring more controlled and secure interactions.

✓ Short address. The vulnerability stems from the EVM’s absence of address validity checking. In the process of encoding during contract invocation, if the encoded arguments’ length is insufficient, the EVM compensates by adding extra zeros to ensure 32 bytes. The AA design, through the involvement of the bundler and EntryPoint contract, can mitigate this issue. The design can effectively check the length of Ethereum addresses via msg.data.

✗ Randomness reliance. This vulnerability revolves around the manipulation of seed (a form of randomness) by malicious miners in gambling and lottery contracts that use pseudorandom number generation. AA might not directly enhance the security of random seed creation. This is because the process of generating random seeds typically involves functions within the contract logic rather than being directly embedded in accounts, which is the primary focus of AA.

✗ Empty account. Malicious actors leverage empty accounts (devoid of nonce, balance, code, and storage) to initiate a DoS attack. These empty accounts still necessitate tracking within the Ethereum state trie and result in extended transaction processing times. AA is not equipped to mitigate this vulnerability, as it currently lacks verification mechanisms for empty accounts. However, the issue has been addressed through the implementation of EIP-161.

✗ Under-price opcodes. Ethereum uses the gas mechanism to deter abuse of computing resources, but this vulnerability emerges when the gas cost for resource consumption is improperly set. The exploitation of under-priced opcodes will consume a disproportionate amount of computing resources. This issue is not specifically addressed by the design of account abstraction, as it pertains to the gas pricing and resource allocation mechanisms within Ethereum.

✗ Stack limit. Solidity would trigger an exception and terminate the call due to its rigid limit of 1,024 frames in the EVM call stack. Malicious actors could recursively call a contract, causing it to reach the maximum stack depth and fail subsequent external calls. While account abstraction cannot inherently address this specific vulnerability, changes in the Ethereum protocol (e.g., EIP-150) can indirectly impact AA as well as other aspects of the Ethereum ecosystem.

✓ Unbounded operations. The vulnerability arises when a contract’s execution demands a greater amount of gas than the permitted block gas limit. This occurs due to the inclusion of unbounded operations, such as loops, within the contract. AA design offers effective solutions to counter such issues in two primary ways: Firstly, the paymaster contract defines a fee policy that establishes clear limitations on gas limits. This mechanism ensures that transactions adhere to predefined gas constraints, preventing situations where execution demands exceed the allowable limit. Secondly, after AA’s update, every loop in smart contracts is invoked by an internal account rather than an external account. This setup grants the contract owner the ability to terminate loops if necessary

✗ Inconsistent call returns. This vulnerability stems from the inconsistency between the two return values from different calling routes: (i) directly referencing the callee contract instance and (ii) using low-level methods like send and call. Route-(i) will return the call back to the caller while Route- (ii) returns false to the caller. The inconsistency in behavior persists in the current state of the Solidity compiler, lacking rectification. AA design does not inherently address this issue, but updates or changes in the Solidity compiler or EVM could potentially influence AA as well.

✗ Pointer unreset. The vulnerability arises from Solidity’s behavior regarding uninitialized compound local variables, which, when not explicitly initialized, leads to the reference defaulting to slot 0 and overwriting content from that point onwards. AA design does not address this particular languagelevel issue, but it’s fortunate that the vulnerability was rectified by updating the version of Solidity.

✗ Outdated compiler. This vulnerability surfaces when a contract is compiled using an outdated compiler that harbors bugs. While AA design may not directly address this concern, it aligns with the solution: opting for an up-to-date compiler can substantially reduce the associated risks. Keeping the compiler current is a key practice to ensure the solidity and security of the compiled contracts.

✓ Unclear constructor name. The vulnerability stems from the misnaming of the constructor function, inadvertently allowing unauthorized parties to take ownership of the contract. While AA design cannot directly solve this issue, it is fortunate that the problem was mitigated through the introduction of the constructor keyword

✗ Type casts. A contract can invoke another contract’s function by directly referencing the callee contract’s instance. However, the verification process carried out by the Solidity compiler only assesses whether the invoked function has been declared, and it doesn’t extend to verifying child functions that the invoked function inherits or parent functions that trigger it. This loophole can lead to unintended function execution. AA design does not offer a solution for this vulnerability, as it stems from Solidity’s insufficient type system. In this context, AA’s mechanisms don’t directly address this issue.

✓ Reentrancy. The vulnerability arises when an external contract initiates a function within the caller contract before the latter’s ongoing execution concludes—essentially manifesting as a cyclic call. This exploitable invocation persists until the caller contract depletes its gas resources. The foundation of this vulnerability can be attributed to two pivotal factors: (i) a contract’s decision-making hinges on specific state variables, which necessitate updating prior to invoking another contract; and (ii) the absence of a predefined gas limit for the transition. The introduction of AA can offer a partial solution to this issue. AA’s advantages, including reduced gas consumption and the ability to control transactions precisely through the paymaster contract, contribute to its potential mitigation. Additionally, user operations are treated as distinct inputs through independent transactions, fostering an environment free from dependencies on other contracts. This segregation of operations enhances security by reducing the risk of vulnerability to such cyclic call-related attacks.

✓ Frozen ether. The vulnerability arises from a scenario in which users can deposit funds into their contract accounts but are unable to later access or spend those deposited funds. Two primary factors contribute to this vulnerability: (i) contracts not furnishing a function for the expenditure of funds, and (ii) the inadvertent or deliberate termination of the callee contract. Account abstraction can offer partial mitigation of this vulnerability due to its transaction batching made by bundlers. With each user-requested operation, such as depositing funds into a smart contract, the transaction bundler gains an enhanced capability to inspect the contract before sending tokens. This heightened level of examination surpasses that of a standard user. The transaction bundler possesses the potential to ensure that operations transpire within the confines of the originating contract’s security.

✗ Upgraded contract. Contract upgrading can be approached through two methods: (i) Dividing a contract into a proxy contract (non-updatable) and a logic contract (updatable). (ii) Employing a registry contract to maintain a record of the updated contracts. While the design of account abstraction is separate from these complexities, its contract functionalities align with its principles of upgradability.

✗ Delegatecall injection. EVM offers an opcode called delegatecall, allowing the bytecode of a callee contract to be inserted into the bytecode of the caller contract. The vulnerability arises due to the possibility that a callee contract can modify state variables within the caller contract. Account abstraction does not inherently provide a distinct method to mitigate this particular vulnerability. The effectiveness of AA’s security in mitigating the issue hinges on its inherent design and solution. Fortunately, addressing this can be achieved via a straightforward means by enhancing its declaration.

✗ Unexpected revert. This vulnerability stems from the situation where a callee contract causes the execution of a caller contract to be reverted. The design of account abstraction does not offer a significantly improved mitigation for this issue, as it fundamentally stems from contract programming practices. Consequently, this vulnerability might still be pertinent even within AA’s contract functionalities.

✓ Manipulated balance. This vulnerability surfaces when a contract’s decision-making relies on the values of this.balance or address(this).balance. These values can be manipulated by an attacker to gain unauthorized access to funds. The design update introduced by AA can potentially influence this vulnerability. In AA, all account addresses are explicitly bound with balances, unlike the implicit nature of the former design. This alteration could impact the dynamics of this vulnerability.

✗ Integer overflow. This vulnerability arises when the result of an arithmetic operation surpasses the range of a Solidity data type. Regrettably, neither the Solidity compiler nor the EVM incorporates mechanisms to identify integer overflow or underflow. Account abstraction design limitations prevent it from overcoming these challenges. However, a solution to mitigate this vulnerability is within reach through the utilization of the SafeMath library, which has already proven effective in handling such arithmetic issues.

✓ Insufficient signature. The vulnerability surfaces when a sender channels funds to multiple recipients via a proxy contract, bypassing individual transactions. In this mechanism, the proxy contract evaluates the authenticity of digital signatures from senders. If these signatures lack essential data (such as nonce or proxy contract address), a malicious recipient can exploit the situation to replay the message repeatedly, facilitating the withdrawal of surplus payments. In AA’s design, the role of the bundler mirrors that of a proxy agent. The bundler manages the accumulation of multiple transactions, functioning as a trusted entity. This approach not only aligns with the principles of a proxy contract but also serves as a safeguard against replay attacks. Further, the adoption of multi-sig techniques in AA can also contribute to the mitigation of issues.

✓ Self-destruct contract. When the owner of a contract or a third party utilizes the self-destruct method to terminate a contract, the contract’s bytecode and storage will be erased. The vulnerability emerges from inadequate authentication mechanisms embedded within the contract. AA can indeed mitigate this issue by introducing multi-factor authentication, a more robust approach. This mandates the approval of multiple parties before a suicide operation is executed. By implementing this safeguard, AA enhances security by fortifying the authentication process and reducing the likelihood of unauthorized termination.

✓ tx.origin. The problem originates from the utilization of tx.origin, a global variable within Solidity that identifies the original EOA responsible for triggering the transaction. The vulnerability arises when a contract employs tx.origin for authorization, thereby exposing it to phishing attacks. AA addresses this concern through its integration of EOA with contract invocation. The integration is pivotal as AA replaces tx.origin with msg.sender in default authentication. This shift is now a necessary step to bolster security against vulnerabilities stemming from tx.origin usage.

✓ Wrong payment. This security issue arises due to the absence of identity verification when a caller invokes a function to transfer Ether to a random address. As seen in the mitigation strategies employed for previous balance-related vulnerabilities, the authentication mechanisms and the role of the bundler within account abstraction can aid in alleviating this problem. This ensures that only authorized entities are permitted to initiate such actions, thwarting unauthorized withdrawals.

✗ Lack of confidentiality. Transaction details within a blockchain are inherently public due to the nature of the technology. While designating a state variable as private can limit other contracts’ access, the value of such a variable can still be inferred from transaction data. It’s worth noting that AA design does not specifically address the intricacies of transaction confidentiality; however, it aligns with the overall progression of smart contract evolution. Mitigation strategies encompass the implementation of cryptographic techniques like commitment schemes [29] and zero-knowledge proofs [30]. Additionally, hardware-based solutions [31] could also be explored to enhance the security of sensitive data within an untrusted environment.

✗ Erroneous visibility. This vulnerability stems from inaccurately defining the visibility of a function, where the default public visibility can be exploited by attackers to improperly access functions. AA design doesn’t directly address this issue but aligns with its solution. This vulnerability is mitigated by requiring explicit specification of function visibility, a measure AA’s design also adheres to.