ANNOUNCEMENT #1: Advisory for TORN Holders for the Patch Proposal (Number removed to not make it dependent on the order)

Announcements
1

ADVISORY:

  • A thread is reserved in #Proposals which will be updated with the only legitimate Patch Proposal tied contract address(es) (see below). All other proposals, even though they may be legitimate, I would absolutely extremely suggest TORN holders to VOTE AGAINST.

  • THIS IS IMPORTANT, BECAUSE it can be expected, that someone will also attempt to publish a set of proposals which may seem like what we intend to do with Patch Proposal. IF THIS HAPPENS, DO NOT BE FOOLED and again, ONLY ONLY ONLY accept a Proposal with FULL COMMUNITY CONSENSUS HERE ON THE FORUM.

  • As such, the Proposal number will possibly not be 22, because someone else could propose something malicious.

Furthermore and less important details,

This is an advisory that totally depends on whether the attacker will execute proposal number 21, which should revert the state changes. So, this assumes the attacker will do it.

Note that addresses were mentioned, as it goes right now, a factory for some contracts will have to be deployed extra. Maybe we can CREATE2 it in forward. Will discuss in other thread.

Because the vulnerability is now known and until we do not deploy, propose and set the proposal, governance is vulnerable to the same exploit that was used to exploit it once.

2

I suggest you initiate Proposition #22

3

We will do this as soon as possible but we need to perform some form of security verification. We’re working on this.

4

Let me actually put it this way instead, we have the option of doing a comprehensive security analysis ourselves.

This is again totally dependent on proposal 21 and state being correct after the fact, but after this the contract is (if state is correct) under control of governance again (whatever the TORN distribution).

This means, there is now the option of rushing the upgrade or not, but if an attacker is able to, after 21, pass a proposal, this also means that an attacker can do this post proposal 22, and so on.

So what the real problem now is, and this is what we are working on other than on proposal 22, is the fact that post-execution, we will need to decide and communicate to holders whether or not we consider the Governance contract safe again such that they can deliberate on locking funds again, although most people are probably sitting with a virtual locked balance inside.

What we’re doing on is a set of tests and a writeup to show and explain the state changes which will happen and why we might consider the contract to be effectively safe again.

5

Let me understand what you mean, it means that it is better to wait for Prop 21 to pass, after the governance rights are returned to the holders, and then propose Prop 22, it is safer, am I right?

6

I will expand further.

Governance safety

Out of the original 483,000 TORN stolen, the hacker has 38,000 left. Once 21 executes, in principle, this is not enough for a majority vote.

This means, if we can prove that the proposal properly reverts state, for which we have already performed some tests and it seems that this is to be the case (but I will be looking in more detail) then governance is already back under control of stakeholders.

The only thing which has to be done, which is something that governance will always have to do, is deny malicious proposals.

The execution delay is 48 hours. That means that Governance, if the proposal passes, and it executes non-maliciously, is safe on the 28th of this month, as long as it keeps denying any malicious proposals after it.

So, in effect, we can use this time to do a security overview of our contracts such that they do not break and monitor the situation up until the 28th.

Patch Proposal

The real issue is in regards to the communication of governance safety.

Governance voters would like to see a patch proposal come out as quickly as possible to fix the issue, but the fact of that matter is that the actual more important thing which communicates safety is proposal 21 itself and not the patch.

What I mean by this is that the Patch Proposal patches something which Governance can always deny, and this is the same as denying any other malicious proposal. So it becomes vital to really only use the forum and this Proposals category as a trusted source, and remove everything else. And we should also do so in future.

This means that in effect, what is more important for us, is verifying and laying out everything in regards to it, and in the meanwhile check that everything we have written with 22 is good, and go over it to see if we can make something better.

A deployment date could be the 25th for the Patch Proposal, something I’ve also discussed, to fill the gap one day before the execution of 21 on the 26th.

If governance really wants the Patch Proposal out earlier, then we will have to consider this and act as such, but I laid out the reasons above for what an approximate game plan is.

1 Like