Open c4-bot-9 opened 8 months ago
raymondfam marked the issue as sufficient quality report
raymondfam marked the issue as duplicate of #18
See #61.
raymondfam marked the issue as duplicate of #22
raymondfam marked the issue as not a duplicate
raymondfam marked the issue as duplicate of #57
3docSec marked the issue as not a duplicate
3docSec marked the issue as duplicate of #18
3docSec changed the severity to QA (Quality Assurance)
3docSec marked the issue as grade-a
Lines of code
https://github.com/code-423n4/2024-03-coinbase/blob/e0573369b865d47fed778de00a7b6df65ab1744e/src/SmartWallet/MultiOwnable.sol#L102-L110
Vulnerability details
The
MultiOwnable
contract, designed to permit multiple owners identified by bytes, poses a vulnerability when integrated into theSmartWallet
. This vulnerability arises from the intricate nature of theSmartWallet
, which supports multiple owners identified by bytes, enabling the utilization of secp256r1 public keys alongside standard Ethereum addresses. Given that theSmartWallet
facilitates signing operations that are replicable across any EVM chain, when those involving account-altering user operations, the complexity of this vulnerability amplifies for affected users.Impact
The vulnerability permits owners to retain unauthorized access even after being purportedly removed. Thus, a simple functionality of removing (for instance a compromised) owner would be exceedingly difficult, if not impossible, especially during critical moments requiring immediate mitigation.
Proof of Concept
In the current implementation of
MultiOwnable
, the methodremoveOwnerAtIndex
is the sole means to remove an owner by its index. However, a critical oversight exists wherein thenextOwnerIndex
is not decremented. While this oversight might seem acceptable since it's primarily utilized for signature validation, it becomes problematic for functionalities dependent on owner index in the current appearance, such as the existing owner removal implementation.Exploiting this vulnerability involves a multi-step process. An attacker can execute a front-running attack utilizing
CoinbaseSmartWallet::executeBatch
, incorporating a remove call for the compromised address, followed by re-adding the same removed address viaMultiOwnable::addOwnerAddress
. This manipulation circumvents theonlyOwner
(where it accept itself) modifier utilized in critical functionalities, ultimately leading to a scenario where legitimate owner removal attempts revert with aNoOwnerAtIndex
error.This exploitation enables the compromised owner to persist in the smart wallet, potentially draining tokens from all associated chains where the smart account operates.
Test Case (Foundry)
This test case will demonstrate how user will suffer from removing no longer controlled owner. For simplicity we use a normal ethereum address which should be a very hard to mitigate if it happens. While if all owners are passkey owners (which I believe this issue in this case is more likely to happen in real life) will be more complicated, involving in the ERC-4337 bundlers and the war of who will run his operation first. Add this test case as part of
test/SmartWallet/CoinbaseSmartWallet/ExecutionBatch.t.sol
Test output
Tools Used
Recommended Mitigation Steps
Consider implementing an owner removal functionality that removes the owner bytes itself no matter what happen under any circumstances.
Assessed type
Error