De-briefing Ethereum’s Parity Predicament: What’s Next?
by Erik Kuebler Nov 10, 2017 6:09 PM EST
After an unidentified actor “accidentally” triggered a series of bugs that destroyed approximately $150 million worth of digital currency, the world waits for a substantive answer — is this vulnerability an anomaly? An “I told you so”? Or a humbling opportunity to secure the Ethereum network?
What Happened?
On November 6, “Devops199,” an alleged amateur programmer, set off a chain of bugs on Parity, a popular digital wallet for Ethereum. These bugs affected multisignature, or “multisig,” accounts — “wallets” that require multiple users to enter their keys before funds can be transferred. The place these wallets connect to is known as a “library” contract.
According to Parity, an attempt to fix a vulnerability that allowed hackers to steal $32 million from multisignature wallets in July of 2017 inadvertently created a second vulnerability in the library contract. This allowed Devops199 to gain control of every multisignature wallet as a sole owner.
After Devops199 realized what had happened, he “killed” (deleted) the code. Unfortunately, this locked all funds into multisignature wallets permanently, with no way to access them.
Because of the functionality of the current blockchain, $150 million worth of ether (ETH), the tradable currency that fuels the Ethereum platform, is now effectively destroyed and inaccessible to anyone.
Among the victims of this bug are several recently successful ICOs that chose to store their funds in a Parity wallet because of its multisig option and compatibility with various hardware wallets.
Parity’s Response (So Far)
On November 7, tweets on Parity’s official Twitter account acknowledged the vulnerability and confirmed that the funds affected are frozen and can’t be moved anywhere.
A day later, on November 8, Parity de-briefed the bug, explaining that it was indeed possible to turn the Parity Wallet Library contract into a regular multisig wallet and become the owner of it, which is exactly what Devops199 did. Parity now has a tool to check if a user/wallet has been affected by the vulnerability.
Parity’s History of Hacks
This isn’t the first time Parity has fallen victim to a security exploit. Parity’s multisignature contracts were previously the target of three thefts totalling 150,000 ether in July of 2017 (the second-largest hack after the DAO fiasco). And losses could have been exponentially higher. However, the “White Hat Group,” a collection of hackers and activists, was able to intervene and drain the majority of other wallets before they could be compromised as well.
Future multi-sig wallets created in all versions of Parity Wallet have no known exploits.
- Official Parity website post following the July 19 hack
Jeff Coleman, an expert in blockchain technologies and currently a researcher and advisor with L4 Ventures, described Parity’s response to the July 19, 2017, attack as “worrying, to say the least.”
Coleman told Bitcoin Magazine that his primary concerns centered around Parity’s immediate response and its tendency to downplay the significance of the compromise, choosing instead to blame a large number of external causes:
They blamed observers for not finding the bug before it was exploited; they blamed lack of incentivization for observers; and they blamed the Solidity language for not blocking access by default to the functions the [Parity team] failed to protect.
He further noted that Parity seemed to be blaming the complexity of the well-audited wallet (which they still believed to be secure) from which they had originally modified their code. And also that Parity didn’t take responsibility for their own inadequate quality control and audit procedures.
S.O.S.?
Developers in the community are desperately trying to find a fix to the Parity predicament. Coleman believes that “from a technological perspective, there is nothing short of a hard fork [a non-backward-compatible change to the Ethereum protocol] to restore the destroyed funds.”
After the DAO hack in 2016, the Ethereum Foundation had already accepted a hard fork to restore lost funds, with the common understanding that this was a sort of “mulligan” — a one-time fix for a young, developing blockchain. This scenario, nevertheless, divided the Ethereum blockchain into two parts and created Ethereum Classic, the original Ethereum blockchain, backed by a community that vehemently opposes editing transaction history to restore lost funds.
Using hard forks as interventions to “correct” worst-case scenarios like this is highly controversial, especially since blockchains are meant to be immutable. So, it’s difficult to convince the Ethereum community to use a hard fork to rescue one team from a mistake. While many acknowledge sympathy for smaller accounts storing personal ETH, sentiment is not as sympathetic for the 300,000 ETH that belonged to the Polkadot Project, a Parity initiative.
Arseny Reutov, an application security researcher for blockchain security firm positive.com, affirmed this community sentiment, while acknowledging that hard forks can be solutions. However, he agrees that Ethereum cannot simply hard fork any time there is a problem on the network. He believes blockchains should expect “more and more high profile thefts and incidents,” and that the problem lies in the infant Ethereum platform itself — specifically, in the native Solidity programming language.
If a Hard Fork Isn’t the Answer, Then What Is?
Both Coleman and Reutov believe that the key to gaining the community support necessary to restore funds is to combine the Parity situation with similar situations in which funds have been lost due to various kinds of mistakes. Coleman referenced those detailed in EIP 156: “Reclaiming of ether in common classes of stuck accounts,” for example.
Coleman also pointed out that in any of these instances, it must be “completely unambiguous who the original owners of the assets were.” The necessary changes could then be made and packaged together in an “already planned hard fork, such as the upcoming Constantinople fork.”
Even so, restoring funds is problematic. Ethereum core developers must discern which mistake-affected funds will be returned to users. Will all funds be returned or only a select few — or will this be a ~500,000 ETH learning experience?
