The DFINITY Security team and R&D team are proposing an open policy and procedure for handling high-risk security patches of the IC. The team is looking for feedback, questions, suggestions, etc…
- Raghavan Sundaravaradan, Engineering Manager (Security) at DFINITY (@rsundar01)
- Sam Burri, VP of Engineering at DFINITY (@samuelburri )
- Ali Piccioni, Team Lead, Internal Developer Experience at DFINITY (@ali.piccioni)
Here we will be discussing the policy and procedure for handling security patches and how it affects open-sourcing the Internet Computer software. The scope of this policy includes the replica software running on node machines and system canisters in the Network Nervous System (NNS) subnet. Currently, the Master and Release Candidate branches of the IC internal GitLab repositories are mirrored to the public IC GitHub repository. So effectively any commits to the Release candidate branches are visible to the public almost immediately. But there are situations where openness can be in direct conflict with security and the most important of them is when the system is being patched for security vulnerabilities. Here we will document the policy and procedure surrounding the application of security patches
Openness is a top priority for the DFINITY Foundation. The community’s participation in shaping and governing the Internet Computer is an important driver for its success. This is evident from the series of open-sourcing efforts that took place following the Genesis event and the foundation’s efforts to shape the governance system into an instrument for community participation. All major changes to the Internet Computer, including changes and upgrades to the platform, are subjected to a proposal and voting process that keeps the community updated and enables members to discuss, approve, and reject proposed changes as well as verify them. It is important to be clear here: openness is key to the IC (and all code upgrades will be public), this policy is the DFINITY foundation being open how it best thinks it can address high CVEs (and protect everyone) sometimes depends on exposing the code upgrade after the proposal. Security patches are very sensitive by nature, and knowledge of a patch can provide a window of opportunity for an adversary to mount an attack on the system before it has been patched. As a result, the DFINITY Foundation has adopted the following policies:
- Due to the sensitive nature of security patches, the foundation will not make the content of security patches public until the entire system has been patched.
- As with any other upgrades, a proposal will be submitted for the community to vote on, aka “bless”, a new version of the artifact. The proposal will contain the checksum of the Internet Computer deployment artifacts. But the main difference is that the community won’t be able to verify the checksum as the code is not yet published.
- The details of the patch will be revealed after a quiet period of 10 days from the time after the successful application of patches to the entire system. The patch activity is considered successful if the applied patch completely mitigated the vulnerability as intended and the system remained stable without any negative side effects as a result of the patch. At this point, the community can verify the checksum included in the proposal in step 2.
A security patch is an update to software or firmware that mitigates existing known vulnerabilities present in them. For the Internet Computer, the security patches applied to the replica software and system canisters running in the Network Nervous System (NNS) are covered by this policy.
The release of a security patch before applying it to the intended system may provide adversaries with adequate information on the anatomy of the vulnerability it is trying to protect and how to exploit it for their gain.
The Internet Computer is a complex piece of software with several distributed nodes. Despite comprehensive testing of the security patch, it is possible that something goes wrong. The quiet period provides ample time to ensure the stability of the system, and would allow a rollback if necessary before the content of the patch is revealed.
Due to the complexity and distributed nature of the Internet Computer, patches and upgrades happen in a staggered manner, covering a few subnets at a time, and the entire process may take several days depending on the complexity of the patch and upgrade. The quiet period starts after 100 percent of the platform has been patched., which is typically when then NNS subnet has been upgraded.