The Foundation development team proposes a Dark Fix mechanism, which provides a way to pre-authorize a specific bug fix without exposing its bytecode on-chain. This is important because the exposed bytecode would point potential attackers to the critical vulnerability, allowing them to exploit it.
With this principle laid out, the Foundation development team believes that there are no further reasons to prolong the Governance Security Module delay activation, and recommends to proceed with a second executive vote.
A Governance Security Module (GSM) with a delay of zero allows for instantaneous patching of critical bugs. However, it opens the system up to a governance attack. Conversely, a non-zero GSM delay enables a set time period to counter governance attacks, where bug patches would sit on-chain for the delay period prior to implementation.
Therefore, we need a GSM delay greater than zero. This solution addresses both the need for a critical bug fix mechanism as well as a defense system to prevent governance attacks.
The Maker Foundation development team has proposed a solution called the Dark Fix Mechanism, which involves the following steps:
- A bug fix is developed and tested.
- Fingerprint the bug fix, referring to it onward as the “dark fix.”
- Use the fingerprint to predetermine a dark fix deploy address.
- The Maker community votes in the dark fix based on trusted third-party attestation (see next section).
- The dark fix is scheduled and a wait period goes into effect until GSM delay has passed.
- Lastly, the dark fix is deployed, via an atomic transaction, where the dark fix bytecode is mapped to the predetermined address and thus, instantly patches the bug.
- Note that if there are any discrepancies in the bytecode, the fix will fail.
For the full technical description of the Dark Fix Mechanism, see the document here.
The Dark Fix mechanism introduces a minimal trust requirement in order to avoid an Emergency Shutdown (ES) of the Maker Protocol. In order to implement a solution, the Maker community needs to decide if the third-party attestation is convincing enough to prefer the pre-approval to an Emergency Shutdown of the Maker Protocol.
It is, therefore, a critical consideration as to which form the attestation should take. The Foundation development team has proposed that a committee of MKR holders be selected, and has also discussed suggested alternatives on last week’s governance call:
- Major MKR Holders Model: The Dark Fix developer team reaches out to a pre-selected committee of MKR holders and shares the details about the critical vulnerability and patch. The selected committee of MKR holders would then sign a transaction confirming their support for the proposed dark fix solution.
- Independent Auditor Attestation: An agreement is signed with an independent auditor in advance to perform an audit when the need arises. When a critical vulnerability is detected, the dark fix development team reaches out to the pre-approved auditor who will vet and vouch for the dark fix solution.
- A Community-appointed Trusted Party: When the dark fix development team is ready with their implementation, they will ask the community to appoint an independent trusted party to attest to the validity of the vulnerability and the dark fix solution.
Benefits of the proposed solution
- A GSM delay can be introduced while maintaining the possibility to safely fix critical vulnerabilities in the system.
- The fingerprint (hash code) is cryptographically secure and cannot be reverse engineered.
- For example, if this crypto primitive is broken, the whole internet is broken.
- The bug fix isn’t deployed until after the delay has passed and then it is immediately applied.
- Emergency Shutdown can still be triggered at any point in time during the GSM delay.
- The community can drop the dark fix spell with an MKR majority vote, preventing it from casting.
Note: The dark fix mechanism still openly signals that there is a known critical vulnerability in the system. This proposed mechanism won’t stop an active attack and the GSM delay would still apply to defensive spells.
Protocol Integration Steps
The proposed solution does not require a change to the Maker protocol. This is because the current governance system already enables the ability to propose a spell that would pre-authorize a dark fix based on its hash code.
From a community standpoint, it is necessary to process the ramifications of this proposal and come to a general understanding and agreement on the accepted approach should the need arise in the future.
- The Maker Foundation development team presented a mechanism for fixing critical protocol vulnerabilities in a system with a GSM delay greater than 0.
- The Dark Fix mechanism provides a way to pre-authorize the patch without exposing the bytecode, which would point attackers to the critical vulnerability.
- This mechanism requires one or more trusted parties vouching for the patch that would be voted in by the MKR community.
- With this principle laid out, the Maker Foundation development team believes that there are no further arguments to prolong the GSM delay activation.
- Review of the template code for dark fix spells by the security community.
- Further discussion is required by the community regarding the proposed dark fix mechanism to fix critical vulnerabilities with a GSM delay greater than 0 in place.
- In parallel, continue with the second GSM activation executive vote. Currently, the community has been asked to signal their support for a second executive vote in this thread.
- On Thursday, February 20th, the Maker Foundation development team will attend the Scientific Governance and Risk call for questions and comments about this proposed solution.
- Scientific Governance and Risk - Thursday, February 13, 2020
- Dark Fix Presentation
Github Repository: https://github.com/makerdao/dss-darkfix
- This repository contains the source code for a spell to conceal bug fix source and bytecode during pause delay. A spell is an un-owned object that performs one action or series of atomic actions (multiple transactions) one time only. This can be thought of as a one-off DSProxy with no owner.