@lukasreschke discovered that GitHub did not require users to reauthenticate when promoting another user to an organization owner. Further internal investigation identified that we also did not require reauthentication when inviting a new user to the organization. If an organization owner’s session was compromised, an attacker could invite a new user to the organization and grant them owner privileges. GitHub introduced sudo mode to balance the need between security and usability while performing potentially dangerous actions on GitHub.com. We addressed the vulnerability by requiring sudo authentication for role management and invitation functionality that could escalate a user’s privilege within an organization.
@lukasreschke reported!!! an issue where a form was not correctly validating its authenticity token, allowing a CSRF attack to import code from external sources into an attacker-specified repository. This caused unexpected branches to appear in the target repository, but would not overwrite any existing code or add code to existing branches.
The cause of the issue was the way that the application handles authenticity token mismatches. The default Rails behavior is to
nil out the session. This can lead to issues with session memoization that may occur before the session is
niled. We modified the application to use a safer method for CSRF handling and now raise a Exception on token mismatch, halting the request chain. This is now the default behavior for newly generated rails applications and can be added to Rails 4 applications with
protect_from_forgery with: :exception. A proposed change to Brakeman would create a new warning for Rails 4 applications that do not use
protect_from_forgery with: :exception.
This vulnerability was considered to be low-risk because no code could be deleted or overwritten, just added. The mitigation for this bug does not affect enterprise installations.