Detailed explanation of Parity contract vulnerability, why a novice developer caused a disaster

A critical security vulnerability in Ethereum’s Parity multi-signature wallet was triggered on November 6, which paralyzed all Parity multi-signature wallets created after July 20.

As you may have seen, Parity published a security advisory today informing its users and developers of the “accidentally” triggered vulnerability, which, according to statistics, resulted in the freezing of more than $150 million worth of Ether, including $90 million of funds belonging to the new project “Polkadot” by Gavin Woods, the founder of Parity and former core developer of Ethereum.

(Loss Statistics)

How long has this vulnerability been around?

As Dan Guido pointed out, this new vulnerable contract has been deployed for more than 100 days since July 20, one day after the original multi-wallet vulnerability was fixed.

Vulnerabilities

A novice developer with the username " devops199 " claimed that he accidentally triggered the vulnerability and reported it through GitHub.

The newly deployed contract 0x863df6bfa4469f3ead0be8f9f2aae51c91a907b4 contains a vulnerability, and its owner is not initialized. As a library, it is possible that "devops199" can transform it into a regular multi-signature wallet, because for Ethereum, there is no substantial difference between accounts, libraries, and contracts.

The incident occurred due to two transactions. The first one took over the library, and the second one killed the library. All multi-signature wallets created after July 20 used this library.

Transaction #1

In the above transaction, the user initialized the owner of the Parity library (0xae7168deb525862f4fee37d987a971b385b96952) using the initWallet() function. Assigning the owner directly to the library allows the user to convert the library into a regular multi-signature wallet.

 // throw unless the contract is not yet initialized.
modifier only_uninitialized { if (m_numOwners > 0) throw; _; }
// constructor - just pass on the owner array to the multiowned and
// the limit to daylimit
function initWallet(address[] _owners, uint _required, uint _daylimit) only_uninitialized {
initDaylimit(_daylimit);
initMultiowned(_owners, _required);
}

Transaction #2

After initially becoming the owner of the library (which has now become a regular multi-sig wallet), this user can call the kill() command, which will cause all wallets that depend on the third-party library to crash. This affects all party wallets created after July 20th, as users can no longer use the library.

 // kills the contract sending everything to `_to`.
function kill(address _to) onlymanyowners(sha3(msg.data)) external {
suicide(_to);
}

in conclusion

Although the vulnerable smart contract was open sourced and deployed several months ago, the vulnerability still managed to escape the scrutiny of the Parity team.

Due to the design of smart contracts, they cannot be easily repaired, which means that once a mistake occurs in the contract, all wallets that rely on this third-party library will suffer.

In fact, the open source nature of libraries is also questionable, and it would be terrible if our daily operating systems did the same.

We have seen a lot of enthusiasm for blockchain smart contracts, and the average user believes that these smart contracts are secure. But just like any other software, smart contracts are vulnerable.

All of the recent security issues surrounding smart contracts have created increasing challenges for storing funds on a blockchain-based software layer.