Another day, another cryptocurrency clusterfuck

Adynathos

@dcoder I posted the same to another topic, repeating here as it contains some explanation:

Another hilarious display of incompetence from the Ethereum client, Parity.
Not long ago, it was possible to take ownership of wallets by calling a public function which should have been private.
Now they have another function that can be called inappropriately, this time it it deletes their code from the chain, makes all wallets using the code useless.
What wrongly-exposed function will they have next month?

https://paritytech.io/blog/security-alert.html

Following the fix for the original multi-sig issue that had been exploited on 19th of July (function visibility), a new version of the Parity Wallet library contract was deployed on 20th of July. However that code still contained another issue - it was possible to turn the Parity Wallet library contract into a regular multi-sig wallet and become an owner of it by calling the initWallet function. It would seem that issue was triggered accidentally 6th Nov 2017 02:33:47 PM +UTC and subsequently a user suicided the library-turned-into-wallet, wiping out the library code which in turn rendered all multi-sig contracts unusable since their logic (any state-modifying function) was inside the library.
This means that currently no funds can be moved out of the multi-sig wallets.

Someone on HN explains what that means:

So here's what happened: Parity used to have a normal multisig wallet, where every user deploys their own contract and each one is a full copy of the code.

They decided it'd be nice if people could have a lower transaction fee when they deployed a new wallet. So they made one master contract that has all the code. Now when you deploy a new wallet, what you actually deploy is a stub that forwards function calls to the master contract, using a "delegatecall" which lets the master execute its functions in the context of the stub contract.

However, they didn't think through how they might want to change the master contract code in this new situation. In particular, they didn't remove the selfdestruct function. Self destruct is perfectly sensible when it's your own contract that you're not using anymore, but it's not so great when it's shared code used by lots of people.

They also forgot to initialize a function setting contract ownership. Someone came along and made themselves the owner, then called the selfdestruct. They posted about it on github, apparently unaware of the full impact of what they'd just done, which was to destroy the code used by all the stub contracts deployed since July 20. Now those stubs no longer have access to functions for withdrawing the ETH they contain.

This master/stub design was also the root cause of Parity's previous multisig hack. Apparently they didn't get a clue and pay for a fresh round of external audits, which I think would have easily caught this problem. In fact, at the end of a post-mortem of the previous hack, published on July 20, they complained that they lacked funds for such things:

https://paritytech.io/blog/the-multi-sig-hack-a-postmortem.html

For added irony, bold claims at parity.io:

0_1510083856200_b84bbde6-db83-41d6-ad17-2e6d02f5c61d-image.png
If this is the most secure way, what are the other ways?

0_1510083832700_ba1c563f-1154-436f-9fbd-37c53713dbf3-image.png

ScholRLEA

Announcing a new cryptocurrency, check. Name dropping blockchain, check. Issuing an ICO, check. Raking in millions of USD by cashing in the investments in the new currency made by people sight unseen, check. Doing the whole thing as the basis for an in-game currency for a new MMO game that is still being produced and doesn't even have a demo yet, and offering pre-order microtransactions for said non-existent-as-of-yet game... Really?

You Can Now Pre-order Microtransactions – 05:59
— Jim Sterling

So, this is a thing, now. Just what we all needed.