GitHub Tightens Rules for Posting Exploits

GitHub has posted changes to the policy regarding the placement of exploits and malware research results, and compliance with the US Digital Millennium Copyright Act (DMCA). The changes are still in the draft state, available for discussion for 30 days. 

The following conditions have been added to the DMCA compliance rules, in addition to the previously present prohibition of distribution and ensuring the installation or delivery of active malware and exploits:

• Explicit prohibition of placing technologies in the repository to bypass technical means of copyright protection, including license keys, as well as programs for generating keys, bypassing key verification and extending the free period of work.
• The procedure for filing an application for the removal of such a code is introduced. The applicant for removal is required to provide technical details, with a declared intent to submit the application for examination prior to blocking.
• When blocking a repository, they promise to provide the ability to export issues and PRs, and offer legal services.

The changes to the exploit and malware policy reflect criticism following Microsoft's removal of a prototype Microsoft Exchange exploit used to carry out attacks. The new rules attempt to explicitly separate the dangerous content used to carry out active attacks from the code that accompanies security research. Changes made:

• It is forbidden not only to attack GitHub users by posting content with exploits on it or to use GitHub as a delivery vehicle for exploits, as it was before, but also to post malicious code and exploits that accompany active attacks. In general, it is not forbidden to place examples of exploits prepared in the course of security studies and affecting already fixed vulnerabilities, but everything will depend on how the term "active attacks" is interpreted.                                  For example, the publication in any form of JavaScript source code that attacks the browser falls under this criterion - the attacker does not prevent anything from downloading the source code to the victim's browser by fetching it, automatically patching it if the exploit prototype is published in an unusable form, and executing it. It is the same with any other code, for example, in C ++ - nothing prevents it from being compiled on the attacked machine and executed. If a repository with such code is found, it is planned not to delete it, but to close access to it.
• The section prohibiting "spam", cheating, participation in the cheating market, programs for violating the rules of any sites, phishing and its attempts have been moved above.
• Added a clause explaining the possibility of filing an appeal in case of disagreement with the blocking.
• Added a requirement for owners of repositories that host potentially dangerous content as part of security research. The presence of such content must be explicitly mentioned at the beginning of the README.md file, and contact information must be provided in the SECURITY.md file. It is stated that, in general, GitHub does not remove exploits published along with security studies for already disclosed vulnerabilities (not 0-day), but reserves the ability to restrict access if it considers that there is still a risk of using these exploits for real attacks and into the service GitHub support has received complaints about the use of code for attacks.