GitLab XSS Via Autocomplete Results
Overview
The SonicWall Capture Labs threat research team became aware of a cross-site scripting vulnerability in GitLab, assessed its impact and developed mitigation measures. GitLab, an open-source code-sharing platform, published an advisory on this vulnerability affecting GitLab CE/EE in all versions starting from 16.7 to 16.8.6, 16.9 before 16.9.4 and 16.10 before 16.10.2. Identified as CVE-2024-2279, it allows remote threat actors to perform arbitrary actions on behalf of victims, earning a high CVSS score of 8.7. To mitigate this threat, GitLab users are strongly encouraged to upgrade their instances to the latest versions, as mentioned in the vendor advisory.
Technical Overview
This vulnerability arises due to a flaw in the input validation mechanism while displaying suggestions to the user using the feature called ‘autocomplete for issues reference’ in the rich text editor. Autocomplete characters are a handy way for users to enter field values into markdown fields swiftly. While creating and displaying an issue enforces the escape of the special characters, the same is missing when the user types the character “#” and the backend engine tries to autocomplete from the list of issues.
This enables an attacker with access to ‘issues’ in the project to create an ‘issue’ using a crafted payload in the title field, leading to stored cross-site scripting. The exploit payload triggers when a victim is trying to mention any issue in the textbox using the autocomplete character #, which leads to an automatic execution of arbitrary action specified in the payload. This could include actions such as requesting a resource from the attacker-controlled server.
An escape method from the Lodash library is used to address this vulnerability, as seen in the related diff between version 16.10.1 and 16.10.2 in Figure 1. This method replaces special characters like &, <, >, “, and ‘ with their corresponding HTML entities before adding them to the Document Object Model (DOM).
Figure 1: Utilization of the escape method to resolve the issue
Triggering the Vulnerability
Leveraging this XSS vulnerability requires the attacker to meet the prerequisites below.
- The attacker must have network access to the target vulnerable system along with the rights to create the ‘issue’.
- The attacker must create an issue with a malformed payload. For instance, Malicious issue <img src=”http[:]//<attacker_controlled_server>/x.svg”>. This payload will load images from the server if the vulnerability is present.
- The victim must try to mention any issue using the autocomplete character #.
Exploitation
While the steps to trigger the vulnerability are straightforward, it can test the attacker’s patience since the exploitation requires the victim to try to mention any issue using the rich text editor, to be specific.
To begin with, the issue needs to be created with the crafted payload as seen in Figure 2. The attacker needs to host the x.svg image file at the server specified in the payload.
Figure 2: Malicious issue creation
The created issue will be listed as shown in Figure 3.
Figure 3: Issues list
When a user tries to refer to any issue by typing # in the rich text box, for instance, in the comment box of any other issue, the payload will be triggered. The exploitation can be verified by checking the access logs of the web server, where the access request on behalf of the victim can be seen, as shown in Figure 4.
Figure 4: Triggering XSS
SonicWall Protections
To ensure SonicWall customers are prepared for any exploitation that may occur due to this vulnerability, the following signatures have been released:
- IPS: 4383 GitLab Autocomplete Results XSS
- IPS: 4385 GitLab Autocomplete Results XSS 2
Remediation Recommendations
GitLab users are strongly encouraged to upgrade their instances to the latest versions as mentioned in the vendor advisory.
Relevant Links
