GitLab is an open-source application developed based on Ruby on Rails. As a Git-repository management platform, GitLab supports access to public or private projects through Web interfaces and is widely used in enterprises.
On March 20, 2017, GitLab released versions 8.17.4, 8.16.8, and 8.15.8 (community edition and enterprise edition). These versions contain security fixes for several high-severity vulnerabilities, including a security fix for a critical information leakage vulnerability, protection against SSRF attacks, a fix for a vulnerability that can leak private email addresses in Atom feeds, and a fix for private repository data leakage into Elasticsearch. Attackers can exploit these vulnerabilities to gain user permissions, which may lead to grave consequences.
See the following for more information about the vulnerability.
GitLab information leakage high-severity vulnerability
The vulnerability can allow an attacker with permission to assign ownership of an issue or merge request to another user to obtain that user’s private token, email token, email address, and encrypted OTP secret. Reporter-level permissions are required to exploit this vulnerability. By using GitLab APIs and sensitive information, the attacker can perform operations with that user’s permissions. If the target user is an administrator, the consequences may be more severe.
This vulnerability is the result of a bug in the serialization of a user object and was created in GitLab 8.7.0.
Condition and method of exploitation
Hackers can exploit this vulnerability to run code remotely.
- 8.7.0 to 8.15.7
- 8.16.0 to 8.16.7
- 8.17.0 to 8.17.3
Follow these steps to detect the vulnerability:
- Open a project.
- Open the issue tracker of the project.
- Create an issue and assign ownership of the issue to another user.
- Check whether sensitive information is included in the returned JSON.
How to fix or mitigate
Upgrade GitLab to one of the following versions: 8.15.8, 8.16.8, or 8.17.4.
Note: Back up snapshots before the upgrade.
Due to the nature of this vulnerability, user tokens may be cached by proxies or browsers. We therefore recommend that all administrators reset private tokens and email tokens for all users as soon as the upgrade is complete.