10,000 pts
@joernchen discovered that the command-line git clone tool does not correctly sanitize submodule URLs. When cloning submodules, for example using git clone --recurse-submodules or git submodule update, the URL of a submodule could be interpreted as a command-line argument to git clone.
As GitHub Desktop recursively clones submodules by default, @joernchen was able to provide a full proof-of-concept that this bug could could trigger arbitrary code execution when cloning a malicious repository. No impact was identified within GitHub.com or in GitHub Enterprise.
We addressed the vulnerability by working with the upstream Git project to fix this specific argument injection and add stricter parameter checks to prevent similar issues in the future. CVE-2018-17456 has been assigned to this vulnerability and can be found in the National Vulnerability Database. On GitHub.com we also added detection for potentially malicious repositories to prevent the exploitation of outdated Git clients.
5,000 pts
@joernchen reported an issue that could have allowed an attacker to execute arbitrary commands on a user’s computer if they had Git LFS installed and cloned a malicious repository. Git LFS supports a per-repository configuration file to customize how certain aspects of Git LFS function. One of these configuration options is parsed and eventually used as a connection URL for an external SSH command. If an attacker crafted a malicious URL it caused SSH to interpret the host portion of the URL as a command-line flag and execute arbitrary commands using the ProxyCommand SSH option. We addressed the vulnerability by changing the way the URL is passed to SSH to prevent it from being interpreted as a flag. Users should upgrade their clients to Git LFS 2.1.1 or later to address this vulnerability.
Neither GitHub.com or GitHub Enterprise are directly affected, as this is a client-side vulnerability. However, if users are using a Git LFS client, they should upgrade their clients as noted above.
3,000 pts
@joernchen reported an issue that could have allowed an attacker to execute arbitrary commands on a user’s computer if they had Git LFS installed and cloned a malicious repository. Git LFS supports a per-repository configuration file to customize how certain aspects of Git LFS function. However, this file also allowed arbitrary Git configuration options to be modified. We addressed the vulnerability by whitelisting the set of per-repository Git LFS configuration options that can be used to a safe subset. Users should upgrade their clients to Git LFS 1.0.1 or later to address this vulnerability.
GitHub Enterprise is not directly affected, as this is a client-side vulnerability and Git LFS is disabled on GitHub Enterprise by default. If Git LFS is enabled, users should upgrade their clients as noted above.
3,000 pts
@joernchen identified that malicious github-windows: URLs could be crafted, leading to arbitrary remote code execution. Only certain browsers would handle these URLs in a way that would lead to code execution. This vulnerability was fixed in version 2.14.7 of the GitHub for Windows application.
500 pts
@joernchen reported a bug where a page listing the members of a team could be viewed by users who were not members of the organization. We addressed this by adding the missing authorization check on this page. We also improved our testing to ensure that this issue does not regress. We also audited related parts of the application to ensure that similar issues are not present.
5,000 pts
@joernchen reported an issue that could potentially allow an attacker to set arbitrary environment variables on GitHub.com frontend servers during SSH Git operations. After review and modifications to the intial submission, we were able to identify a set of circumstances in which this was possible.
Environment variables were being set based on key/value pairs being passed over HTTP from one backend service to another. By injecting metacharacters in user controlled values, an attacker would have been able to add arbitrary key/value pairs. @joernchen also shared a few tricks that could have allowed an attacker to leaverage this vulnerability to execute arbitrary commands.
We addressed the vulnerability by stripping metacharacters from user controlled data before using it in environment variables. We have also performed a full audit of related code to ensure that there were no similar vulnerabilities.
1,000 pts
@joernchen reported an issue where we weren’t adequately rate limiting attempts at two-factor authentication. If an attacker already had obtained a user’s password, this could allow them to make unlimited guesses at two-factor codes. We addressed this by expanding our existing rate limiting to include two-factor authentication attempts.
1,000 pts
Joernchen reported a bug that could allow an attacker to bypass API authentication for specific users of organizations. The problem resulted from the way MySQL compares numeric values in a query against string columns. This was resolved by forcing parameters into the correct type before using them in queries and also by disabling the input of parameters in ways that allow type to be specified by the user. Joernchen wrote a great blog post about this type of vulnerability in general.
Thanks joernchen, for participating in the beta test of this program.
