On Monday November 6th 2017 02:33:47 PM UTC, a vulnerability in the “library” smart contract code, deployed as a shared component of all Parity multi-sig wallets deployed after July 20th 2017, was found by an anonymous user. The user decided to exploit this vulnerability and made himself the “owner” of the library contract. Subsequently, the user destructed this component. Since Parity multi-signature wallets depend on this component, this action blocked funds in 587 wallets holding a total amount of 513,774.16 Ether as well as additional tokens. Subsequent to destroying the library component, someone (purportedly this same user) posted under the username of “devops199” issue #6995 that prompted our investigation into this matter.
All other functionality of the Parity Wallet (UI) continues to have no known vulnerabilities. This includes all standard, non-multi-sig accounts.
We have reached out to affected users and are encouraging all those that we have not yet been able to reach to contact us firstname.lastname@example.org. We recognise that the issue has, among other things, caused distress and anxiety about the future of projects and funds in our community and we are working hard to explore all feasible solutions.
We’ve had a lot of discussions and analyses across the team since the exploit happened. In this post, we would like to shed some light on factors relevant to the issue and provide responses to questions and complaints raised in the aftermath of the exploit.
The original "Foundation" multi-sig wallet code was created and audited by the Ethereum Foundation's DEV team, Parity Technologies and others in the community. Many users rely on it, and it underwent extensive peer review. This body of code continues to have no known security issues. It was restructured by the Parity team into a lightweight "stub" smart contract which is deployed to the network every time a wallet is created, together with a much heavier "library" smart contract, containing the majority of the wallet's logic and which is deployed only once. While there was no formal audit, the contract had received many reviews internally and externally in the context of analyses of the July 19th exploit and the returning of the funds by the White Hat Group both before and after deployment in July.
In an attempt to stay as close as possible to the original audited smart contract, as few changes as possible were made to derive the library contract. This, however, meant that the library contract had the same functionality as a regular wallet and required initialization. It therefore also still contained the original
self-destruct function that is designed for retiring the wallet.
In the aftermath of the attack on July 19th 2017, we fixed and re-deployed the library contract on July 20th 2017.
In August, a Github contributor called “3esmit” recommended a code change that
initWallet should be called when being deployed which at the time was considered a convenience enhancement. Thus, we committed this proposed enhancement to the library contract that would automatically initialize it by calling
initWallet on construction. Interpreting the recommendation as enhancement, the changed code was to be deployed in a regular update at a future point in time.
On November 6th 03:25:21 PM +UTC, ‘devops199’ identified the uninitialised owner in the contract deployed in July and chose to initialise it, thereby setting themselves as the owner. Subsequently, devops199 chose to kill the library contract.
There are essentially two main ways this exploit could have been avoided. If the contract code had not included the functionality to suicide or kill, even if someone had taken ownership, they would not have been able to do anything. The kill functionality was a remainder of the original audited contract. The other way would have been for the wallet initialisation to have been done as proposed by 3esmit, either automatically through the code change and re-deployment or manually on the contract deployed in July.
Parity Technologies regularly employs external auditors for formal audits of smart contracts that we write. For example, our KYC service PICOPS as well as sale contracts for ICOs that we assist with, have stringent audit requirements.
However, rather than just having more audits, we strongly believe that more extensive and formal procedures and tooling around the deployment, monitoring and testing of contracts will be needed to achieve security. We believe that the entire ecosytem as a whole is in urgent need of such procedures and tooling to prevent similar issues from happening again, in particular if and when the number and complexity of live contracts grows.
We deeply regret the situation and we are working hard on several Ethereum improvement proposals(EIPs), both contributing to previously existing ones and suggesting new ones that have the potential to unblock funds. These improvement proposals will also address general cases of blocked funds.
There is no timeline for when such an improvement proposal could be implemented; we will follow the will of the community and go through the regular EIP process like any other protocol improvement. Parity Technologies will handle much of the development work around these proposals and work constructively with the Ethereum Foundation team and the community towards further protocol layer development. We are committed to the continued development of Ethereum.
Parity Technologies remains committed to being at the vanguard of Ethereum technology development and we will work diligently to develop secure and useful technology for the community.