The 2.12 series release notes contain important changes in this release series.

Meltdown & Spectre

Meltdown (CVE-2017-5754) and Spectre (CVE-2017-5753 and CVE-2017-5715) exploit critical vulnerabilities in modern processors. These hardware vulnerabilities allow programs to extract data which is currently processed on the same machine. This also can affect GitHub Enterprise.

The risk to GitHub Enterprise depends on the environment that it runs in. There are two main vectors of attack that need to be considered.

Virtualization platform

Given that GitHub Enterprise runs on various virtualization platforms, it's essential to update the virtualization platform where possible to mitigate any of these issues. The existing patches and fixes almost all focus on solving Meltdown. Meltdown is more straightforward to fix and most providers focus on this first.

Spectre is more complicated to exploit and also more complicated to fix. KVM for example is not vulnerable to Meltdown but is vulnerable, with a proof of concept, to Spectre which was tested by Google in the project originally (see https://googleprojectzero.blogspot.nl/2018/01/reading-privileged-memory-with-side.html). Specifically under "Reading host memory from a KVM guest". This Spectre exploit tested against a specific kernel version, but nothing implies it's impossible to adapt for other kernel versions and or other virtualization platforms.

The following Cloud and virtualization platforms have released announcements and/or fixes.

• On AWS we use HVM for virtualization. According to Amazon, HVM is not vulnerable to Meltdown. Also see https://aws.amazon.com/security/security-bulletins/AWS-2018-013/
• Xen VMs using PV virtualization are vulnerable. We recommend switching to HVM virtualization as HVM is not vulnerable to Meltdown. Also see https://xenbits.xen.org/xsa/advisory-254.html under "Mitigation".
• Google Cloud is not vulnerable to Meltdown as VMs there are isolated and cross VM attacks are not possible.
  See their FAQ and the Google Cloud Security Bulletins page.
• Microsoft Azure is updating/rebooting infrastructure where necessary to mitigate potential hypervisor level issues. See https://azure.microsoft.com/en-us/blog/securing-azure-customers-from-cpu-vulnerability/.
• VMWare has released patches to address this at the hypervisor level: https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html & https://lists.vmware.com/pipermail/security-announce/2018/000397.html. We strongly encourage customers install those patches.
• Intel has also announced they will be releasing updates for their processors. If the host platform you run GitHub Enterprise on has these patches available in the future, we also strongly recommend installing those.

Inside GitHub Enterprise

The vulnerability can also be exploited if there is code under the control of an attacker running on the same system. GitHub Enterprise has very limited support for custom code in the form of pre-receive hooks. Pre-receive hooks are limited such that administrators are the only ones who can set them up and their runtime execution is limited to 5 seconds. Both these aspects greatly limit the risk of data exposure through pre-receive hooks. As a general rule, administrators should ensure that only known and trusted pre-receive hooks are enabled on their appliance.

GitHub Enterprise is based on Debian Jessie. A fix for Meltdown is not yet available for Debian Jessie, as can be seen in the Debian CVE tracker for Meltdown. The new kernel version will be included in a future release of GitHub Enterprise and can potentially come with a performance regression. Accordingly, we recommend testing that release before putting it into production.

Summary

The primary risk for GitHub Enterprise installations is cross-guest or host <-> guest data leakage on the virtualization platform. This may be mitigated by the support cloud hosting providers, or by the suppliers of virtualization software. There is very limited risk of externally supplied software running within the appliance obtaining data from other processes, mitigated by administrators only enabling pre-receive hooks that are reviewed and trusted.

Security Fixes

• LOW: Pre-receive hooks could access internal cloud platform metadata. The metadata resources have been restricted to the root user.
• Packages have been updated to the latest security versions.

Bug Fixes

• Changing the parent of a nested team can result in the nested team not receiving updated inherited permissions.
• Changes to legal hold state of a repository did not trigger an audit log event.
• After changing HTTP proxy configuration in the Management Console, webhooks did not use the settings unless hookshot-resqued was restarted manually.
• NUMA enabled appliances could crash with a kernel panic. This was a known issue with linux-image-3.16.51-2.
• GitHub Apps referenced an invalid profile in the notifications and comment views.
• The pre-receive hook $GITHUB_PULL_REQUEST_AUTHOR_LOGIN environment variable was empty when pull requests were merged via the API.
• Permission update notifications for GitHub Apps were not sent to organization administrators.

Changes

• GitHub Enterprise support ticket creation via e-mail (enterprise@github.com) has been disabled. Please contact GitHub Enterprise Support using the Submitting a ticket article.

Known Issues

• We incorrectly redirect to the dashboard if you accessed GitHub Enterprise using an alias while in private mode. This might happen if you set a fully qualified domain name but the subdomain resolves correctly.
• Images uploaded to issues save with an absolute URL, so they can be broken if the hostname changes.
• On a freshly set up GitHub Enterprise without any users, an attacker could create the first admin user.
• Custom firewall rules aren't maintained during an upgrade.
• svn checkout may timeout while the repository data cache is being built. In most cases, subsequent svn checkout attempts will succeed.
• Git LFS tracked files uploaded through the web interface are incorrectly added directly to the repository.
• GitHub Enterprise clustering can not be configured without https.
• Deleting a search index doesn't delete all associated metadata, which are then incorrectly reused if a new search index is created. This causes search index repair jobs to be reported as finished in the site admin when they were not.
• GitHub Apps silently fail to be created when the name contains an underscore.
• Pull request review comments migrated with ghe-migrator are displayed in the wrong order.
• The pull request review request has users reversed, after migration with ghe-migrator.
• The comment count in the "Conversation" tab of a pull request migrated with ghe-migrator can be wrong.
• The create team API endpoint returns a 500 error if LDAP Sync is enabled and the team already exists.
• The ghe-repl-status command-line utility incorrectly shows TypeError: no implicit conversion of Symbol into Integer when there are repositories or gists with bad replica counts. (updated 2018-01-10)
• Reviewers and the "Review requested" status disappear on pull requests migrated with ghe-migrator. (updated 2018-01-12)
• Background job logging to /var/log/github/production.log may consume large amounts of disk space. The fast growth of this log file could cause the root disk to fill up. (updated 2018-01-16)
• Large API requests may trigger excessive logging in the exceptions log. (updated 2018-01-31)
• The gpgverify service may consume large amounts of CPU time even when not processing requests. (updated 2018-02-14)
• Pull request reviewer usernames were not updated if a reviewer was mapped to a different username when migrating repositories using ghe-migrator. (updated 2018-04-12)
• On a repository that's been locked for migration using ghe-migrator, project boards are not exported. (updated 2018-05-07)
• Nameid-format matching on SAML response is too strict when value is "unspecified", which can cause an error with the "Another user already owns the account." message if the IdP changes NameID. (updated 2018-06-25)

Thanks!

The GitHub Team