@adob reported a XSS vulnerability in the GitHub API when rendering Markdown with a maliciously formatted attribute value. The GitHub Markdown API allows callers to render Markdown as HTML. The provided Markdown is translated to HTML using our “HTML pipeline” before it is rendered and returned. This pipeline consists of a number of filters, one of which is responsible for “autolinking” URLs into clickable links in the resulting HTML. @adob discovered a way to use the script macros syntax to format an element’s attribute value in a way that caused the autolink logic to incorrectly generate a link and the resulting HTML to be malformed. As a result, an attacker could inject arbitrary HTML in the result.
While this API was never used on GitHub.com, we still took the threat seriously. We addressed the XSS vulnerability by removing support for script macros from our vendored copy of libxml2 that is used by Nokogiri. We have no use for script macros when parsing HTML and it is what caused the autolink logic to parse its input incorrectly.
@adob reported a XSS vulnerability when rendering a maliciously formatted task list. Throughout GitHub.com users can provide markup that is translated to HTML using our “HTML pipeline” before it is rendered and displayed. This pipeline consists of a number of filters, one of which is responsible for translating task lists into HTML. @adob discovered a way to format a task list item so that it would render incorrectly and cause the resulting HTML to be malformed. In combination with using script macros to avoid escaping HTML attribute values, an attacker could inject arbitrary HTML in the rendered result.
While this issue was mitigated by our use of CSP, we still took the threat seriously. We addressed the XSS vulnerability by modifying our task list filter logic to parse task list items more strictly. In addition, we further mitigated this, and potential future issues, by removing support for script macros from our vendored copy of libxml2 that is used by Nokogiri. We have no use for script macros when parsing HTML and it provides a potentially dangerous vector for attackers. While unescaped attribute values are not inherently unsafe, they can be when paired with bugs such as the one in our task list filter.
@adob reported an XSS vulnerability that could be triggered by setting HTML content in a user’s profile that would be returned by the GitHub API. This data was subsequently queried by a GitHub web application and inserted unsafely into the DOM using innerHTML. This lead to DOM-based XSS.
While exploitation of this vulnerability only occurred within a static HTML site, with no user session or sensitive information, we still took the threat seriously. We addressed the behavior by replacing DOM manipulation using innerHTML with a safe alternative.
@adob discovered a DOM based XSS vulnerability within the wiki functionality on GitHub.com. By setting an appropriate attribute on an HTML tag, @adob was able to leverage existing GitHub JavaScript to insert arbitrary HTML markup into the DOM. While our CSP policy prevented injection of JavaScript, @adob was able to leverage additional GitHub JavaScript to trigger an event handler that automatically submitted an injected HTML form element.
We addressed the DOM XSS vulnerability by further restricting the allowed attributes for HTML tags in markup. In addition, we are auditing and modifying multiple client and server side components to further reduce the risk associated with injected static HTML (such as forms).
@adob reported an issue that could have allowed an attacker to instantiate arbitrary Ruby objects on the servers used to generate GitHub Pages sites. GitHub Pages had recently upgraded to a newer version of Jekyll that disabled safe_yaml support for monkey patching YAML#load to be secure by default. An attacker could commit a malicious _config.yml file to their Pages repository that would cause an arbitrary object to be deserialized, possibly leading to remote code execution on the server. We addressed the vulnerability by explicitly enabling the safe_yaml gem for all of GitHub Pages.
@adob reported an issue that could have allowed an attacker to read arbitrary files on the servers used to generate GitHub Pages sites. We addressed the vulnerability by improving the file path sanitization that is done when generating a GitHub Pages site. We also performed an audit to ensure we were not using unsanitized file paths elsewhere in GitHub Pages.
@adob reported an issue that allowed an attacker to instantiate arbitrary Ruby objects on a server used for GitHub Service Hooks. Several service hooks use XMLRPC to serialize data between GitHub and the service hook endpoint. A malicious service hook endpoint could generate an XML response that would cause the hook service to dynamically instantiate an arbitrary Ruby object. Though object instantiation does not directly lead to remote code execution (RCE), it can often be used to do so. As a result, we treated the finding as a RCE and addressed the vulnerability immediately.
We addressed the vulnerability by disabling support for object marshalling in our XMLRPC configuration. We also performed an audit to ensure we were not using an insecure XMLRPC configuration elsewhere.
@adob discovered a DOM based XSS vulnerability in GitHub.com. By setting an appropriate attribute on an HTML tag, @adob was able to leverage existing GitHub JavaScript to insert arbitrary HTML markup into the DOM. In addition, @adob was able to exploit a Chrome browser bug to bypass our Content Security Policy (CSP) policy. These two bugs, in combination, would allow execution of user-controlled JavaScript on GitHub.com.
While this XSS was browser specific, Chrome is the most popular browser on GitHub.com. We addressed the DOM XSS vulnerability by further restricting the allowed attributes for HTML tags in markup. In addition, we have modified our CSP policy to work around the bug in Chrome.
@adob identified that Referer headers could be leaked through specially crafted cross-origin image requests. In combination with a previously reported vulnerability in our OAuth redirect URI path parsing, this could lead to the disclosure of sensitive information passed to Gist on OAuth redirects. We remediated this issue by making more robust checks when rewriting links to our image proxy.
@adob reported a stored XSS vulnerability within GeoJSON rendering on render.github.com. While exploitation of this vulnerability was limited to a sandboxed domain, we still took the threat seriously. We addressed the behavior by properly escaping user-controlled input.
@adob reported a persistent XSS vulnerability that existed within our contributors graph page. If the the default branch name for a repository contained HTML markup, the unescaped branch name was used on the contributors graph page.
While exploitation of this vulnerability was prevented by our use of CSP, we still took the threat seriously. We addressed the behavior by properly escaping the branch name.
@adob reported an issue where an endpoint on GitHub.com could be tricked into serving content that Adobe Flash would interpret as a Flash movie. Flash will treat any file as a Flash movie, regardless of file extension or the values of the Content-Type or X-Content-Type-Options headers. A malicious website could host an embed tag with the src pointing to the vulnerable endpoint on GitHub.com. Even though the Flash movie would be loaded by the malicious site, Flash would allow the movie to make HTTPS requests to GitHub.com and to read the response, including any sensitive information such as CSRF tokens.
The only ways to prevent Flash from interpreting a resource as a Flash movie are to not allow user control of the first bytes of the response or to set the Content-Disposition header to attachment. We addressed the vulnerability by removing the feature that required the vulnerable endpoint.
@adob reported an issue where Adobe Flash would interpret raw Gists as Flash movies. Flash will treat any file as a Flash movie, regardless of file extension or the values of the Content-Type or X-Content-Type-Options headers. A malicious website could host an embed tag with the src pointing to a raw Gist. Even though the Flash movie would be loaded by the malicious site, Flash would allow the movie to make HTTPS requests to gist.github.com and to read the response, including any sensitive information such as CSRF tokens.
The only ways to prevent Flash from interpreting a resource as a Flash movie are to not allow user control of the first bytes of the response or to set the Content-Disposition header to attachment. We mitigated the vulnerability by hosting the user-controlled data on a sandbox domain where potentially serving Flash files is not dangerous.
@adob discovered several flaws in our parsing of URLs for redirection. An attacker could have exploited these flaws to redirect users from GitHub.com to arbitrary sites. Some of the flaws also could have been abused to gain access to OAuth applications as another user. We have addressed this issue by improving our redirect URL checking.
