Cowrie Research

parity-multisig-wallet-initwallet-ownership-reset-2017-07-19

13 min read

Parity Multisig Wallet initWallet Ownership-Reset Drain (2017-07-19)

  • Name: Parity multisig wallet initWallet ownership-reset drain
  • Date: 2017-07-19
  • Protocol: Parity multisig wallet
  • Chain: Ethereum
  • Category: unprotected initializer / re-initialization ownership takeover / delegatecall wallet drain
  • Loss: about 153,037 ETH stolen from three publicly highlighted multisig wallets, commonly described as roughly 32M at the time
  • Summary: Parity’s multisig wallet design moved constructor logic into the shared WalletLibrary inside js/src/contracts/snippets/enhanced-wallet.sol and let each wallet instance forward unmatched calldata there through a fallback delegatecall. In that library, initWallet(address[] _owners, uint _required, uint _daylimit) stayed publicly callable and simply chained initDaylimit(...) plus initMultiowned(...) without any only-uninitialized guard. Because delegatecall preserved the attacker’s msg.sender, re-running initWallet on a live wallet rewrote the wallet’s own owner map, confirmation threshold, and daily-limit spending parameters. The attacker used that to seize control of deployed multisigs and then invoke execute() to transfer out the ETH. The exploit did not require stolen keys or a second bug: initialization itself was the ownership takeover.
  • Trigger / entry point:
    • Affected Parity multisig wallets exposed a fallback that delegated arbitrary calldata to the shared wallet library.
    • WalletLibrary.initWallet(...) contained constructor-style setup logic for owners and daily limit, but it was a normal public function in deployed runtime code.
    • There was no effective one-time guard preventing initWallet(...) from being called again on already-initialized wallet instances.
  • Root cause:
    • Parity refactored constructor logic into a library-callable initializer without preserving the can only happen once security property of a real constructor.
    • The wallet fallback delegated all unknown calldata to the library, so initWallet(...) was not just reachable during deployment; it remained reachable by any external caller afterward.
    • In the shipped library code, initWallet(...) only called initDaylimit(_daylimit) and initMultiowned(_owners, _required). initMultiowned(...) then wrote m_owners[1] = uint(msg.sender), populated additional owners from _owners, and assigned m_required = _required; no prior-initialization or existing-owner check blocked the rewrite.
    • Because those writes landed in the wallet instance’s storage through delegatecall, re-running the initializer was equivalent to replacing the wallet’s authentication and spending policy in one shot.
    • The exploit boundary was therefore not withdrawal auth in the usual sense. It was the earlier question of who still had the power to define wallet ownership at all.
  • Exploit path:
    1. The attacker targeted vulnerable Parity multisig wallet instances holding large ICO treasuries.
    2. For each victim wallet, they sent an initWallet(address[] _owners, uint _required, uint _daylimit) call directly to the wallet address, relying on fallback delegatecall to route execution into WalletLibrary.
    3. The attacker supplied attacker-controlled initialization parameters, including their EOA 0xb3764761e297d6f121e79c32a65829cd1ddb4d32 and a very large _daylimit so a direct ETH send would clear the wallet’s single-owner daily-spend fast path after takeover.
    4. Because initWallet(...) lacked a one-time initialization check, the call overwrote the existing multisig owner configuration and spending parameters in the wallet’s own storage.
    5. Now recognized as an owner under attacker-chosen policy, the attacker called execute(address _to, uint _value, bytes _data) on each compromised wallet.
    6. The wallets transferred ETH to the attacker’s address under the rewritten authorization model.
  • What the attacker needed to be true:
    • The wallet had to use the vulnerable Parity library-based multisig design from the affected release line.
    • The wallet fallback had to delegate arbitrary calldata into WalletLibrary.
    • initWallet(...) had to remain callable after deployment and write ownership state without checking whether initialization had already occurred.
    • The wallet needed to hold enough ETH or tokens to make the ownership reset worth exploiting.
  • Technical anatomy worth remembering:
    • This was a canonical constructor turned back into a public function failure.
    • The dangerous part was not just delegatecall exists; it was the combination of broad fallback dispatch plus privileged setup code still living in ordinary runtime bytecode.
    • In the vulnerable source commit, OpenZeppelin’s contemporaneous review highlighted initWallet(...) at line 216 and the catch-all wallet fallback _walletLibrary.delegatecall(msg.data) at line 424 of enhanced-wallet.sol.
    • delegatecall preserved msg.sender, which meant initMultiowned(...) wrote the attacker into m_owners directly when the initializer was replayed through a wallet instance.
    • The attacker did not need to satisfy the old multisig threshold. They simply replaced the wallet’s auth and spending parameters, then used Parity’s normal execute() path to move funds under the new state.
    • The incident is a clean example of why initialization is part of protocol auth, not just deployment boilerplate.
  • Representative transactions and contracts:
    • Attacker EOA: 0xb3764761e297d6f121e79c32a65829cd1ddb4d32
    • Edgeless multisig wallet: 0x91efffb9c6cd3a66474688d0a48aa6ecfe515aa5
    • Swarm City multisig wallet: 0x50126e8fcb9be29f83c6bbd913cc85b40eaf86fc
    • æternity multisig wallet: 0xbec591de75b8699a3ba52f073428822d0bfc0d7e
    • Edgeless initWallet takeover tx: 0xff261a49c61861884d0509dac46ed67577a7d48cb73c2f51f149c0bf96b29660
    • Swarm City initWallet takeover tx: 0x2e65274f2bcc729a1fe6c2b44138b1da3642fca19d6419054a13ed8fa3933c2d
    • æternity initWallet takeover tx: 0x9dbf0326a03a2a3719c27be4fa69aacc9857fd231a8d9dcaede4bb083def75ec
    • Edgeless drain tx highlighted in public reconciliation: 0x0e0d16475d2ac6a4802437a35a21776e5c9b681a77fef1693b0badbb6afdb083
    • Swarm City drain tx highlighted in public reconciliation: 0x97f7662322d56e1c54bd1bab39bccf98bc736fcb9c7e61640e6ff1f633637d38
    • æternity drain tx highlighted in public reconciliation: 0xeef10fc5170f669b86c4cd0444882a96087221325f8bf2f55d6188633aa7be7c
  • Response / mitigation:
    • Parity publicly warned users to move funds from vulnerable multisigs immediately.
    • The White Hat Group scanned for contracts with the same vulnerable bytecode, identified 570 similarly exposed multisigs, and from blocks 4044813 through 4046151 executed about 3,986 rescue transactions to sweep exposed ETH and tokens before the blackhat could reach them.
    • Public reconciliation work tracked the main whitehat rescue wallet 0x1dba1131000664b884a1ba238464159892252d3a and estimated roughly $80.46M of ETH plus roughly $84.43M of tokens recovered there, with an additional smaller rescue using 0x1ff21eca1c3ba96ed53783ab9c92ffbf77862584 and 0xd1f27c48b948d49f3d098f499b8a1830d8a7e229.
    • Public analysis after the incident emphasized that constructor extraction plus unrestricted fallback delegation was an unsafe pattern, and that initialization logic needed explicit one-time protection.

Three governance-authority promotions this incident collapsed

  1. A deployment-only setup path was still allowed to remain a live wallet control surface

    • The dangerous fact was not merely that initWallet(...) existed in source. It was that Parity’s wallet fallback still forwarded arbitrary calldata into WalletLibrary, so constructor-shaped setup code remained callable on funded production wallets.
    • OpenZeppelin’s contemporaneous writeup and the shipped enhanced-wallet.sol both preserve the key shape: initWallet(...) stayed in runtime code, and the fallback still did _walletLibrary.delegatecall(msg.data) for unmatched calldata.

  2. That replayed setup path was still promoted into canonical owner / threshold truth

    • Calling initWallet(...) again did not just tweak metadata. Through initMultiowned(...), it rewrote m_owners, m_ownerIndex, and m_required in the wallet’s own storage.
    • Once the attacker supplied themselves as owner with a one-signature threshold and enormous daily limit, the protocol had already accepted attacker-authored governance truth for the wallet itself.

  3. That accepted owner truth still retained immediate treasury-spending authority

    • The exploit did not need a second authorization bypass after takeover. The attacker simply used the wallet’s ordinary execute() path under the newly rewritten owner and threshold policy.
    • That is why the incident is so clean analytically: a live setup surface remained reachable, that setup surface still defined canonical wallet authority, and that authority still inherited immediate ETH-release power.

The durable lesson is that constructor-like helper still exists, that helper can still define who the owners are, and those owners still deserve live spend authority are three separate promotions. Parity collapsed all three.

Pattern tags

  • unprotected-initializer-reinitialization
  • Constructor logic was extracted into a shared runtime library, but the one-time setup only property never survived the move from constructor to callable function
  • Wallet fallback delegatecall turned a deployment helper into a permanently reachable live admin surface
  • Re-running initWallet(...) did not merely toggle a flag; it rewrote the owner set, threshold, and daily-limit parameters that defined the wallet’s authorization boundary
  • The same replayable setup path that looked like deployment plumbing became a direct treasury-drain path once funded multisigs were already live

Why the exploit worked

  • Parity treated deployment-time authority as ordinary runtime authority. initWallet(...) was supposed to stand in for constructor behavior, but nothing in live execution prevented outsiders from calling it again after funds were already custodied.
  • The wallet’s catch-all fallback made the problem economically reachable. Because unmatched calldata was blindly delegated into WalletLibrary, any public library function inherited the wallet’s full storage authority.
  • delegatecall preserved the caller context that mattered most. When initMultiowned(...) wrote m_owners[1] = uint(msg.sender), it wrote the attacker’s address into the victim wallet’s owner table, not into the library’s state.
  • Parity’s spend logic then amplified the takeover instead of resisting it. After ownership and spending parameters were rewritten, the attacker could use the wallet’s normal execute() path to move ETH under the newly attacker-authored policy.
  • This was therefore not a clever bypass of an otherwise sound multisig. It was a root-of-trust failure: the wallet never stopped outsiders from re-running the ceremony that decided who the owners were.

Detection and audit pivots

  • Treat every constructor-refactor helper (initWallet, initialize, setup) as an authorization surface, not as deployment boilerplate. Ask whether it is reachable on live funded instances and whether a second call changes root auth.
  • Trace every fallback delegatecall edge into shared libraries or implementations. If a wallet or proxy forwards arbitrary calldata, then every externally visible function in the callee is part of the attack surface unless explicit routing narrows it.
  • Ask which state writes actually establish trust: owner arrays, thresholds, spending limits, module pointers, recovery authorities, and admin slots. If any of those can still be rewritten by a setup path, the system is still effectively uninitialized.
  • Model the attack in two steps: redefine owners and use normal privileged function. Reviews that focus only on the second step miss the real exploit surface.
  • Monitor for impossible post-launch events: initialization-like calls on funded instances, sudden owner-set rewrites, threshold resets, or new daily-limit values appearing without a legitimate governance or signer ceremony.

Failure-prevention checklist

  • Make deployment-time trust anchoring atomic. A wallet should not exist in a funded or relied-upon state while constructor-equivalent selectors like initWallet(...) still decide who the owners are.
  • Deauthorize setup verbs after rollout. If constructor logic must be refactored into runtime code, the live instance should permanently fail closed on any later attempt to call those selectors.
  • Keep fallback routing narrower than full library ABI reachability. A catch-all delegatecall(msg.data) surface turns every externally visible helper in the callee into a production entrypoint, including the ones authors mentally classified as deployment-only.
  • Treat owner-set initialization, threshold assignment, and daily-limit configuration as one root-of-trust object. Reviews should prove that none of those slots can ever be rewritten by a post-deploy helper path.
  • Make shared libraries and singleton code objects directly harmless. If a deployed helper contract remains callable, it should not retain the power to define ownership or spend policy for dependent wallets.
  • Add invariant tests for cannot become fresh again: once owners are set, repeated initializer calls, alternate selector routing, and fallback-dispatched library calls must all fail.
  • Monitor funded instances for impossible setup activity. Post-launch calls to initWallet, sudden owner-table rewrites, threshold resets, or unusual daily-limit jumps should page operators as likely active compromise.
  • Design rescue tooling before disclosure. If one replayable setup bug can instantly turn into mass wallet seizure, prebuilt pause, migration, or whitehat-sweep procedures are part of the security model rather than optional incident-response polish.

Audit prompts

  • Which exact selectors decide the wallet’s first trust anchor, and can any of them still be reached after funds arrive?
  • Does any fallback, proxy, or library dispatch path make deployment-only setup code callable on a live wallet instance?
  • If constructor logic was moved into a library or initializer, what concrete mechanism proves it is one-time in the wallet’s real storage domain rather than only by convention?
  • Which writes actually define wallet control: owner arrays, owner indexes, required confirmations, spend limits, module pointers, or recovery roles? Can any setup helper still mutate them?
  • Could a caller who becomes owner through replayed setup immediately use an ordinary post-setup path like execute() or changeOwner() to cash out, meaning the real bug sits one layer earlier than the visible theft?
  • Are shared code objects directly callable, and if so, what prevents them from acting as hidden admin surfaces for every dependent wallet?
  • If this bug became public today, how would operators identify all affected instances and distinguish legitimate migration from active hostile re-initialization?
  • Do tests assert the negative property that funded wallets can never emit initialization-shaped state transitions again, even through fallback-routed calldata?

Lessons that should already be standard

  • Constructor logic does not become less security-critical just because it moved into a library function. If anything, it becomes more dangerous because runtime reachability has to be rebuilt deliberately rather than assumed away.
  • Broad fallback delegatecall is not neutral plumbing. It is an API design choice that can silently promote deployment helpers into live treasury-control surfaces.
  • Initialization is part of authentication, not deployment ceremony. If an attacker can replay setup, every later permission check is already operating on attacker-authored truth.
  • Wallet reviews should ask who can still define the owners? before they ask who can withdraw? Parity shows the second question can look perfectly fine while the first one is already lost.
  • Shared-library architectures need lifecycle discipline, not just code reuse discipline. A library that remains empowered after rollout is still part of the wallet’s control plane.
  • Incident response that requires racing attackers to exploit hundreds of your own users first is evidence that the design lacked graceful containment long before disclosure.

Why this incident matters

  • It remains one of the cleanest demonstrations that re-initialization is not a niche configuration bug; it is often a direct ownership takeover.
  • It preserved a durable lesson for proxy, library, and wallet design: broad delegatecall routing turns shared code into a live control plane unless setup verbs are deliberately extinguished.
  • It also foreshadowed the second Parity multisig disaster later in 2017. Once constructor logic and critical authority live in shared-library patterns, initialization mistakes can produce both theft and fleet-wide bricking.
  • The whitehat rescue response is part of the historical lesson too: the same flaw that let the blackhat steal 153,037 ETH forced defenders into a race to exploit 570 other wallets first, which is a sign that the architecture left almost no graceful containment path once the bug was public.

Internal linkages

  • Core recurring pattern: unprotected-initializer-reinitialization.
  • Positive-design companion: implementation-and-singleton-direct-call-deauthorization — useful when the sharper question is why shared runtime code, bootstrap helpers, or library-style components should have been made directly harmless once production wallets depended on them.
  • Positive-design companion: decommissioning-authority-extinguishment-discipline — useful when the sharper lifecycle question is how deployment-only selectors and setup routines should have been provably extinguished after rollout.
  • Strong follow-on case: [[parity-multisig-walletlibrary-uninitialized-selfdestruct-freeze-2017-11-06.md|Parity WalletLibrary uninitialized-singleton selfdestruct freeze]] — the later 2017 Parity incident where the shared library itself retained too much live authority and a different initialization failure bricked dependent multisigs instead of draining them.
  • Modern ecosystem branch: shared-code-singleton-retained-authority-bricking — useful when the sharper question is why one supposedly passive shared code object can still redefine or destroy many dependent instances at once.
  • Modern upgradeability analogue: [[openzeppelin-uupsupgradeable-uninitialized-implementation-selfdestruct-bricking-near-miss-2021-09-09.md|OpenZeppelin UUPSUpgradeable uninitialized-implementation selfdestruct bricking near miss]] — same family, newer proxy idioms.

Control surface

Graph View

Backlinks