Persistent XSS via e-mail when creating merge requests
This issue took 16 Days and 14 hours to triage and 179 Days and 0 hours to close the report once triaged.
Discovered by mario-areias on Gitlab
Summary: The vulnerability consists in the ability to create branch names that contain characters such as
<>/. This branch name is sent via e-mail which is rendered as HTML.
Description: One way to exploit this is by forking a repository. Then an attacker would create a branch called
<script>alert(1)</script>and make a simple change. Now the attacker creates a merge request to the original repository and assign a reviewer to it. The reviewer will receive the e-mail with the branch name not sanitised.
Another way to exploit is to by adding Gitlab users to a repository the attacker controls and assign them to review merge requests.
Steps To Reproduce:
Note: These instructions work on GDK with the latest version. I wasn't sure if it is allowed to test something like on gitlab.com
- Choose a public repository and fork it (let's say HTML5 boilerplate)
- Go through the repository main page http://yourserver:3000/root/html5-boilerplate
- Click on the button + button and select New File
- Create any file but choose a different target branch (something like <script>alert(1)</script>
- Gitlab will direct you to a page to create a new merge request from your recently create branch to master. Ignore that.
- Open a New Merge Request
- Select Source Branch as your fork and the recently created branch
- As for Target branch select the original repo and master
- Click submit
- Select one the maintainers of the original repo
- Go to letter opener (/rails/letter_opener/)
- See the alert popping up.
The steps above only require UI, but an attacker can create a branch name through git client as well. The create branch option UI protects against this attack.
There is also another version of the attack, where a repository owner can add any Gitlab users to become members of her repo. The attacker now create a Merge Request in his own repo and assign the new member to it. Same result.
- Vulnerable code at
gitlab-ce/app/views/notify/new_merge_request_email.html.hamlline 6. This is the exploit above.
- Vulnerable code at
gitlab-ce/app/views/notify/repository_push_email.text.hamlline 49. I haven't created an exploit for this one, but I would assume it should be similar.
E-mail clients nowadays are well protected against XSS. However, a malicious user could use Gitlab's name to mislead users. The problem with this vulnerability is the reach. It is my understanding, an attacker can add whoever is a Gitlab user as a member of her own repo. So she could send malicious e-mails to them. I would usually say that is a low vulnerability, however, given the number of users that could be affected I would say is a medium