GitHub CEO Nat Friedman speaks at GitHub Universe 2020. GitHub on Thursday solicited the comments of the security research community on its new, apparently stricter policies for posting malware and proof-of-concept exploits. (GitHub)
GitHub on Thursday solicited the comments of the security research community on its new, apparently stricter policies for posting malware and proof-of-concept exploits. But the response may have been more than it bargained for.
Some of the changes date back to a month ago when GitHub, which is owned by Microsoft, removed a proof-of-concept exploit for the so-called ProxyLogOn vulnerabilities in Microsoft Exchange that have led to more than 100,000 server infections. There were also other incidents dating back more than a year in which GitHub repositories were found to be infected with malware and capable of being exploited in a supply chain attack.
GitHub, which researchers use as a platform where they can test and experiment, said in a blog post that these updates also focus on removing ambiguity in how the platform will define terms such as “exploit,” “malware,” and “delivery” – the platform’s effort to clearly state its expectations and intentions.
Security researchers expressed skepticism, arguing that if or when software ever gets removed, GitHub would have to outline a very clear-cut and transparent reason; otherwise, users will likely rebel and flee to other platforms, said Sean Nikkel, senior cyber threat intel analyst at Digital Shadows.
Nikkel said some researchers have raised great points with existing off-the-shelf, legitimate tools such as Metasploit or Mimikatz, or other similar software that adversaries frequently abuse.
“Are these now also illegitimate? While starting the public discussion is a significant step, transparency around the end goal and the future will need to be spelled out clearly to GitHub users,” Nikkel said. “Suppose GitHub does end up taking stronger steps towards locking down what’s acceptable on the platform. In that case, the conditions of what they understand as an actual attack or threat would also need to be spelled out fairly clearly, and in terms that would be understood by the security community and general users of the platform.”
While it’s a nice gesture from GitHub to make the platform more security researcher-friendly, while also trying to regulate the content that’s uploaded, “ideas aren’t always easy to realize in the way they were originally expected,” said Kamila Tukhvatullina, security analyst, Lucy Security.
“This dilemma has existed for as long as GitHub has been a popular place for storing code,” Tukhvatullina said. “Researchers have been publishing (and still do) malware, ransomware samples, exploits and tools for penetration. It’s a double-sided coin: GitHub’s a great platform to share with fellow researchers and showcase your work, but also in the end, it’s a free source of material for cyber criminals. I find it a sensitive topic and don’t expect both parties – GitHub and researchers – to find a consensus soon.”
Outcries from researchers led to a response from Github, which Chief Security Officer Mike Hanley posting that clearly, “our attempt to provide clarity here has fallen short and has led to some interpretations that don’t match our intention.”
“Hello again. I wanted to chime in with a few additional thoughts based on the response so far from the community, as well as clarify a few points, particularly that our intention is not to introduce a policy change, but rather clarify existing language,” Hanley wrote. “We’re reading every piece of feedback and are grateful that you’re taking the time to comment here. We are listening and learning from it.”
Hanley continued with a number of clarifications. First, he said that GitHub allows, supports, and promotes software that is dual use, which would not change. Second, GitHub’s intent is not necessarily to change policy, but to clarify what crosses the line into a policy violation. Third, initial language around “harm” was too broad and the concern that implementing this as-is would be a regression. Fourth, that the updated language asks for a security contact for dual use projects, but does not require it. And finally, that GitHub does not aim to dictate how vulnerability disclosure occurs on the platform as policy, but does encourage a maintainer-centric approach.
“We take our role as an impartial and trusted code custodian with all the gravity it deserves, and welcome debate and feedback as your voice is central to our mission of ensuring GitHub is a home for developers and security researchers alike,” Hanley wrote.
This report was updated to reflect posted response from GitHub.