GitHub: Here's how we're changing our rules around malware and software vulnerability research
Microsoft-owned GitHub has updated its policies on sharing malware and exploits on the site to better support security researchers sharing so-called "dual-use" software – or software that can be used for security research but which might be used to attack networks.
It admits the language it previously used was "overly broad".
Security
"We explicitly permit dual-use security technologies and content related to research into vulnerabilities, malware, and exploits," says Michael Hanley, chief security officer of GitHub, in a blogpost.
SEE: Network security policy (TechRepublic Premium)
Dual-use technologies include tools like the Metasploit framework and Mimikatz, which are used by defenders, ransomware attackers and state-sponsored threat actors to compromise networks and move around networks after they're compromised.
"While many of these tools can be abused, we do not intend or want to adjudicate intent or solve the question of abuse of dual-use projects that are hosted on GitHub," the company said in its pull request regarding exploit and malware policies.
"Many of the projects cited in this ongoing discussion, such as mimikatz, metasploit, and others are all incredibly valuable tools and the goal is to further protect from what we felt was overly broad language in our existing [Acceptable Use Policies] that could be viewed as hostile toward these projects as-written."
GitHub has also clarified when it may disrupt ongoing attacks that are using GitHub as a content delivery network (CDN) to distribute exploits or malware. GitHub acknowledged its language around the term "harm" was too broad.
"We do not allow use of GitHub in direct support of unlawful attacks that cause technical harm, which we've further defined as overconsumption of resources, physical damage, downtime, denial of service, or data loss," notes Hanley.
It also updated sections of the policy that ask researchers working on dual-use projects to provide a point of contact, but this is not mandatory.
The policy update follows a review that GitHub initiated in April after it took down code from researcher Nguyen Jang in March. Jang had posted proof-of-concept (PoC) exploit code targeting two of four zero-day vulnerabilities – dubbed ProxyLogon – affecting on-premise Exchange servers.
Microsoft released patches for the bugs on March 2, but warned that a Chinese state-sponsored group Hafnium had been exploiting the flaws before it released patches. Microsoft also warned that the bugs could be quickly exploited by other threat actors before customers applied patches.
On March 9, Jang shared his proof-of-concept exploit on GitHub, as reported by The Record. While being just a PoC for two of Exchange flaws, the code could be tweaked with little effort to exploit vulnerable Exchange email servers and gain remote code execution, according to experts.
And at that point, many organizations still hadn't patched affected Exchange servers.
SEE: Cloud computing: Microsoft sets out new data storage options for European customers
Per Motherboard, GitHub took Jang's PoC down a few hours after he posted it because of the potential damage it could cause, but acknowledged that PoC exploit code could be helpful to the security community for research purposes.
GitHub came under fire from security researchers because it looked like it was making an exception for PoC exploit code affecting parent Microsoft's software while allowing researchers to share PoC code for non-Microsoft products on the site, as Google security researcher Tavis Ormandy pointed out on Twitter.
The other policy option is to ban sharing PoC exploit code, but Ormandy argued this would be a bad outcome for defenders.
"I'm saying that security pros benefit from openly sharing research and access to tools, and they make us safer. We could say "no sharing", so there is only black market access to exploits. I don't think that's a win," wrote Ormandy.