The GitLab Web Interface Does Not Guarantee Information Integrity When Downloading Source Code from Releases.
HackerOne report #2574561 by st4nly0n on 2024-06-25, assigned to GitLab Team:
Report | Attachments | How To Reproduce
Report
Description:
The GitLab.com web interface presents a vulnerability that compromises the integrity of files downloaded from a repository via a release. Although the web interface displays seemingly secure confirmations, there is a possibility that the downloaded files contain malicious content. This is because, when a tag related to a release is deleted from the command line, the GitLab web interface continues to show the release as associated with the original confirmation. An attacker can exploit this situation by creating a branch with the same name as the deleted tag, thereby allowing the content to be changed and compromising the integrity of the files to be downloaded.
Steps To Reproduce:
Steps as the Repository Owner:
1. Create an empty repository.
2. Invite a user with developer permissions.
3. Clone the repository and navigate into it:
git clone <REPO_URL>
cd <REPO_DIR>
4. Create a file named hello.sh with harmless content:
printf 'echo "hello world"' > hello.sh
5. Snapshot the hello.sh file and push it to the remote:
git add hello.sh && \
git commit -m 'Add hello.sh' && \
git push origin HEAD
Steps as the Attacker (invited user in step 2):
6. Clone the repository and navigate into it:
git clone <REPO_URL>
cd <REPO_DIR>
7. Create a tag named version1 that points to the harmless commit (in this case, HEAD):
git tag version1
8. Push the tag to the remote:
git push origin --tags
9. Create a release of the version1 tag in the web interface.
10. Delete the tag from the remote:
git push origin -d version1
11. Create a branch named version1:
git checkout -b 'version1'
12. Modify the hello.sh file with a malicious payload:
printf 'cat /etc/passwd' > hello.sh
13. Push the changes to the remote:
git add hello.sh && \
git commit -m 'Add hello.sh' && \
git push origin HEAD
Steps as the Victim:
14. From the web interface, navigate to the -/releases page and note that there is a release. Verify the checksum (sha1/commit) to ensure it corresponds to the harmless change of the hello.sh file.
- Go back and download the source code (Source code (zip)) from the release assets.
- Once downloaded, execute the hello.sh file and note how it does not execute what was shown in the web interface, but rather executes the malicious payload.
PoC Video
The following proof-of-concept video shows how the victim verifies the file contents before downloading them from the release. However, upon downloading and executing the source code, the malicious code is executed instead of the harmless code displayed in the web interface's release confirmation.
poc.mp4
What is the current bug behavior?
The GitLab web interface does not guarantee the integrity of files when downloading source code from a release.
What is the expected correct behavior?
The information presented in the GitLab web interface about changes made to any file should match what the end-user will obtain when downloading the source code from a release.
Output of checks
This bug happens on GitLab.com
Impact
This vulnerability could allow an attacker to introduce malicious content into the files of a release, thereby compromising the integrity and security of the files downloaded by users through the GitLab.com web interface. Depending on the nature of the malicious content, this could result in unauthorized code execution, acquisition of confidential information, or other adverse impacts on user security.
Attachments
Warning: Attachments received through HackerOne, please exercise caution!
Proposal
Call Releases::DestroyService in Git::TagPushService, to match Tags::DestroyService (which is used by the UI/API).