:warning: **Please read [the process](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/developer.md) on how to fix security issues before starting to work on the issue. Vulnerabilities must be fixed in a security mirror.** **[HackerOne report #2574561](https://hackerone.com/reports/2574561)** by `st4nly0n` on 2024-06-25, assigned to `GitLab Team`: [Report](#report) | [Attachments](#attachments) | [How To Reproduce](#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: ```bash git clone <REPO_URL> cd <REPO_DIR> ```   **4**. Create a file named `hello.sh` with harmless content: ```bash printf 'echo "hello world"' > hello.sh ```   **5**. Snapshot the `hello.sh` file and push it to the remote: ```bash 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: ```bash git clone <REPO_URL> cd <REPO_DIR> ```   **7**. Create a tag named `version1` that points to the harmless commit *(in this case, HEAD)*: ```bash git tag version1 ```   **8**. Push the tag to the remote: ```bash git push origin --tags ```   **9**. Create a release of the `version1` tag in the web interface. **10**. Delete the tag from the remote: ```bash git push origin -d version1 ```   **11**. Create a branch named `version1`: ```bash git checkout -b 'version1' ```   **12**. Modify the `hello.sh` file with a malicious payload: ```bash printf 'cat /etc/passwd' > hello.sh ```   **13**. Push the changes to the remote: ```bash 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.    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! * [poc.mp4](https://h1.sec.gitlab.net/a/5be482af-7d69-44de-b134-db660b0d7880/poc.mp4) ### Proposal Call `Releases::DestroyService` in [`Git::TagPushService`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/git/tag_push_service.rb), to match `Tags::DestroyService` (which is used by the UI/API).