The cybersecurity community is unhappy with the planned changes to GitHub’s policies about security testing, vulnerabilities, and malware.
On proposed clarifications about exploits and malware hosted on GitHub, the group has until June 1 to provide feedback.
“Our policy updates emphasise the distinction between actively malicious content, which is prohibited on the web, and at-rest code used to support security research, which is welcomed and encouraged. “These updates also concentrate on eliminating uncertainty about how we use words like ‘exploit,”malware,’ and ‘delivery,’ to encourage clarification of both our goals and intentions,” GitHub CSO Mike Hanley wrote in a blog post on Thursday.
“These changes are intended to set specific guidelines for the security research community on how GitHub reacts to abuse reports relating to malware and exploits on the platform, as well as provide insight into how GitHub determines whether or not to limit projects,” he added.
The proposed changes come after a proof-of-concept (PoC) exploit for the recently revealed Microsoft Exchange vulnerabilities was removed from the Microsoft-owned code sharing service, which has been used in numerous attacks. Some in the cybersecurity industry were dissatisfied with the decision, claiming that it was possibly removed solely because it targeted Microsoft devices, despite the fact that similar exploits targeting other vendors’ applications had not been removed.
The PoC was removed in compliance with GitHub’s permissible usage policy at the time, and some experts pointed out that GitHub had previously removed exploits targeting other vendors’ goods, implying that the Exchange exploit wasn’t removed solely because it was harmful to Microsoft.
To prevent potential issues, GitHub needs to change its policies about malware and exploits.
GitHub’s revised policy states, “Under no circumstances can users upload, publish, host, execute, or share any content that: contains or instals malware or exploits that are in support of ongoing and active attacks that are causing damage.”
“GitHub will usually not delete exploits in support of vulnerability reporting or security research into identified vulnerabilities,” according to one paragraph added to the GitHub group guidelines. GitHub can, however, limit content if we decide that it still poses a danger in cases where we receive active abuse reports and maintainers are working to resolve.”
The policy changes are unpopular with the majority of those who got input.
“By using language in your usage policy that says things like ‘contains or instals malware or exploits that are in support of ongoing and successful attacks that are causing harm,’ you’re basically declaring yourself the police of what constitutes ‘causing harm.’ That may be an exploit proof of concept for one user, but the entire metasploit system for another,” said Jason Lang, senior security consultant at TrustedSec.
The use of phrases like “help of ongoing and successful attacks” is “a vague catchall that’s difficult to decide whether anyone has breached,” according to Errata Security’s Robert Graham.
“Hackers have already automated the download of my code in their attacks, which means I’m theoretically breaking the new rules,” Graham explained.
In response to the criticism, Hanley said that the organisation would consider the input received.
