: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 #1940441](https://hackerone.com/reports/1940441)** by `inspector-ambitious` on 2023-04-10, assigned to @fvpotvin: [Report](#report) | [Attachments](#attachments) | [How To Reproduce](#how-to-reproduce) ## Report #### Summary ##### Introduction I previously reported #1831547 and #1831543, they have been closed and fixed. However I wanted to retest them carefully over the weekend and I managed to replicate the issue again but this time using a branch called `heads/main` ! ##### A quick recap about symbolic ref names The following is extracted from this [documentation](https://git-scm.com/docs/gitrevisions#Documentation/gitrevisions.txt-emltrefnamegtemegemmasterememheadsmasterememrefsheadsmasterem). > A symbolic ref name. E.g. `master` typically means the commit object referenced by `refs/heads/master`. If you happen to have both `heads/master` and `tags/master`, you can explicitly say heads/master to tell Git which one you mean. When ambiguous, a `<refname>` is disambiguated by taking the first match in the following rules: > > If $GIT_DIR/`<refname>` exists, that is what you mean (this is usually useful only for HEAD, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD and CHERRY_PICK_HEAD); > > - otherwise, refs/`<refname>` if it exists; > > - otherwise, refs/tags/`<refname>` if it exists; > > - otherwise, refs/heads/`<refname>` if it exists; > > - otherwise, refs/remotes/`<refname>` if it exists; > > - otherwise, refs/remotes/`<refname>`/HEAD if it exists. In the following exploitation scenario, we're going to abuse the fact that the following symbolic reference name `heads/foo`, can resolve to two distinct branches either `refs/heads/foo` or `refs/heads/heads/foo`. #### Steps to reproduce This scenario was tested on `gitlab.com`. ##### Step 1: The malicious `heads/main` default branch A user named `victim01` creates an empty new repository named `ambiguity` (without a README).  `victim01` will then create a branch named `heads/main` containing a malicious script named `./script.sh`. That branch will become the default branch since the repository was empty. From the command line, it would look like this ```bash git clone git@gitlab.com:evilcorporation/ambiguity.git cd ambiguity echo "echo 'execute malicious code'" >> script.sh chmod +x script.sh git add script.sh git commit -m "malicious script" git branch -M hack git push origin hack:refs/heads/heads/main ```  Note in the screenshot above that the default branch is `heads/main` and the commit name is `malicious script`. ##### Step 2: The genuine `main` branch Then `victim01` creates a `main` branch in the repository containing as well a `./script.sh` but this time the content of `./script.sh` is genuine and safe to execute. From the command line, it would look like this ```bash mkdir ambiguity_genuine cdambiguity_genuine echo "echo 'this is genuine'" >> script.sh chmod +x script.sh git init git add script.sh git commit -m "genuine script" git branch -M genuine git remote add origin git@gitlab.com:evilcorporation/ambiguity.git git push origin genuine:refs/heads/main ``` ##### Step 3: The victim clone the repo and execute the script Now let's say the user `user1` goes to the repository `https://gitlab.com/evilcorporation/ambiguity.git/`, `user1` will see the following.   While the default branch is `heads/main`, `user1` will see the content of `main` branch instead, note the commit name `genuine script`. And if `user1` was cloning the repository and executing `script.sh`, it will be the malicious code that would be executed instead.  I also tested the download of the zip file and it is vulnerable this time ! (contrary to previous report), the `victim` would download the content `heads/main` branch, see below the extraction of the zip and the output of `script.sh`  ### Output of checks This bug happens on GitLab.com ### Impact Malicious repositories could be created to lure users into executing what they think is safe code, resulting in the takeover of the victim system. ## Attachments **Warning:** Attachments received through HackerOne, please exercise caution! * [image.png](https://h1.sec.gitlab.net/a/d57fd175-428a-41d4-8b2c-c79c4fc4f483/image.png) * [image.png](https://h1.sec.gitlab.net/a/4d8d2cc3-4a3c-4133-bb5b-9847b868ce46/image.png) * [image.png](https://h1.sec.gitlab.net/a/eba01920-7e97-4f82-a91d-78eea650ecaa/image.png) * [image.png](https://h1.sec.gitlab.net/a/7e6b119b-6472-4d61-9c76-5a8846b7bf18/image.png) * [image.png](https://h1.sec.gitlab.net/a/dd0e64d0-b8e6-4bc6-95c2-f2d0e41cd461/image.png) * [image.png](https://h1.sec.gitlab.net/a/d688ebcf-e033-41bb-92f8-b13dc052c617/image.png) ## How To Reproduce Please add [reproducibility information] to this section: 1. 1. 1. [reproducibility information]: https://about.gitlab.com/handbook/engineering/security/#reproducibility-on-security-issues