@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.
@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.
@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.
@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.
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.