GitLab is an open-source, web-based tool that allows developers and teams to effortlessly manage their projects, support continuous integration, and endorse collaboration among team members. With widespread adoption across the globe, GitLab has secured its position as a go-to tool, making it imperative to discover and address any vulnerabilities that may impact its users.

In this post, we will discuss a Denial of Service (DoS) vulnerability, identified as CVE-2024-1947, which affects GitLab CE (Community Edition) and EE (Enterprise Edition). The vulnerability is present in versions 13.2.4 up to but not including 16.10.6, 16.11 before 16.11.3, and 17. before 17..1. We will explore how an attacker can exploit this vulnerability to disrupt the services provided by GitLab, along with the necessary steps for mitigating such risks.

A Brief Overview of the Vulnerability

A denial of service (DoS) attack aims to render a system or service inaccessible to its intended users. In the context of GitLab, an attacker could exploit this vulnerability by sending carefully crafted API calls, which could potentially cause the server to become unresponsive and disrupt its normal functionality.

The Exploit Details

To understand the nature and impact of this vulnerability, let's first examine a code snippet responsible for the issue. The vulnerable function can be found in app/controllers/api/v4/projects_controller.rb:

def create
  ...
  build_project_params
  ...
end

def build_project_params
  ...
  if import_params_present?
    project_params[:import_data_attributes] = import_data_params
  end
  ...
end

def import_data_params
  params.tap do |data|
    data.require(:import_data_attributes).permit!
  end
end

As seen in the code snippet, the build_project_params function checks if import_params_present? and allows all import data passed through the user-controlled input parameter import_data_attributes. By crafting an API call with a malicious payload in the import_data_attributes parameter, an attacker can trigger a DoS condition.

Here's an example of a crafted API call targeting this vulnerability

POST /api/v4/projects HTTP/1.1
Host: gitlab.example.com 
Content-Type: application/json
Authorization: Bearer <YOUR_ACCESS_TOKEN>

{
  "name": "example-project",
  "import_data_attributes": {
    <MALICIOUS_PAYLOAD>
  }
}

Mitigation Steps and Patch Information

The GitLab team has already acknowledged this vulnerability and addressed it through the following patches:

- For GitLab CE/EE versions 13.2.4 to 16.10.5, upgrade to version 16.10.6
- For GitLab CE/EE versions 16.11. to 16.11.2, upgrade to version 16.11.3
- For GitLab CE/EE version 17.., upgrade to version 17..1

Regularly updating your GitLab instance ensures that you are protected from such vulnerabilities. We highly recommend promptly applying these patches to safeguard your GitLab deployment against potential DoS attacks.

Conclusion

It is vital to stay informed about security vulnerabilities in the tools that we use daily, such as GitLab. By being aware of CVE-2024-1947 and its impact, developers and teams can take steps to protect themselves against potential DoS attacks. Maintaining regular software updates and following secure development practices can help minimize the risk of security issues affecting the availability and integrity of your projects and services.

For more information on this vulnerability and the associated patches, refer to the original GitLab Security Advisory.

Timeline

Published on: 05/23/2024 11:15:23 UTC
Last modified on: 05/24/2024 01:15:30 UTC