Another Parity Wallet hack explained

Today yet another vulnerability is discovered in Parity’s implementation of multi-sig contracts deployed after July 20th. The scale of hack is much larger than a previous one, total amount of lost tokens is 514k ETH (~$155M). How and why this happened?

How?

Parity’s multisig wallet consists of two parts: a lightweight contract which is deployed every time when you create a new wallet and the “library” contract which contains the majority of wallet logic and is deployed only once. This is done to reduce gas usage when creating a new contract, and this is good if you implement it right. But what happens? Yes, this “library” had the significant error and right now this “library” is dead, so as all tokens stored on dependent contracts.

Why do I say library with quotes? Because it’s not an actual library, it’s a contract! So when parity’s devs deployed some common code as a “library” they actually deployed an uninitialized wallet and someone who knows about it can initialize this wallet (at least now it can be initialized only once, it’s a huge improvement since last vulnerability!). And eventually, someone did it. It could be the end of the story, but this “library” contains one more interesting function:

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

And since someone initialized this wallet and add them as an owner they can kill it too. And since all other parity’s multisig wallets depend on this contract they are now completely unavailable, it’s literally leftpad all over again.

How can we fix it?

There is no way to fix it without another hard fork. But rewind decentralized, distributed, immutable and tamper-proof ledger is a slippery slope you know.

Why?

So, why the fuck this happened? Less than 4 months ago they fixed a vulnerability in this code and here we go again. Can we blame solidity because default function visibility is public like we blamed last time? No, we can’t.

Can we blame parity’s devs? De jure we can’t, since they waived responsibility in their license. But what about de facto? Let’s read postmortem from last vulnerability.

we treat security and consensus code extremely seriously at Parity

Is that a reason for “annoyance” tag assigned to a security issue?

The first and biggest change will be to ensure that any alterations to the codebase that involve live contract code (which can be generally identified through .sol files) be reviewed by Solidity experts

I think even not Solidity expert can that this contract misusing core concepts of language and it can be malicious. So, did they actually review it?

Can we don’t blame folks who store money on this wallets? No, we can’t. Fool me once, shame on you. But fool me twice, and shame will be on me. Personally, for me, they lost credibility after the first vulnerability in July, but things are much worse, they still used their own version instead of community audited version.

Can we blame the guy who did this? Someone probably can and will do, but he did nothing wrong. If you leave big red button for launching nuclear missiles available for everyone someone sooner or later, intentionally or not will press it. If not this guy maybe a few days later some vulnerability scanner would call some public method for the same effect, will you blame heartless bot too?