How to Fix CVE-2023-5009- A Critical Vulnerability in GitLab Scan Execution Policies?

Security researcher Johan Carlsson (joaxcar) recently disclosed a critical severity vulnerability in GitLab Scan Execution Policies that could enable an attacker to run pipelines as an arbitrary user via scheduled security scan policies. GitLab published details about this vulnerability on Sep 18, 2023, upon releasing a patch to address the flaw. The vulnerability tracked as CVE-2023-5009, has a CVSS score of 9.6, making it critical in severity. Successful exploitation of this vulnerability could allow attackers to access sensitive information or leverage elevated permissions to modify source code or run arbitrary code on affected systems. In this blog post will cover what CI/CD pipelines are, provide background on GitLab and scan execution policies, discuss the details of CVE-2023-5009, list affected versions, outline mitigations, and explain how to fix CVE-2023-5009 by applying the patch.

What Are CI/CD pipelines?

Continuous integration and continuous delivery (CI/CD) pipelines are an essential part of the modern software development lifecycle. They allow developers to rapidly build, test, and release new software versions and updates in an efficient, consistent, and automated manner.

CI/CD pipelines provide the following key benefits:

  • Automate the build, test, and deployment processes, enabling much faster release cycles compared to manual processes. New code changes can go from commit to production in hours or minutes rather than weeks or months.
  • Reduce errors from repetitive manual tasks and provide consistency across environments from dev to prod.
  • Enable practices like infrastructure as code, test automation, and progressive delivery.
  • Catch integration, security, and compliance issues early through automated testing at each stage of the pipeline.
  • Provide visibility into the end-to-end development process with logs and reports.
  • Support continuous iteration and improvement of the pipeline to optimize the SDLC.
  • Facilitate collaboration by centralizing all development processes around the pipeline.

With today’s demand for rapid delivery of software, using CI/CD pipelines is critical for scaling development while maintaining quality. The automated flows enabled by pipelines help teams ship faster, reduce risks, and spend more time building features rather than managing environments. They are essential for following modern development best practices.

A Short Introduction of GitLab and Its Key Features

GitLab is one of the most popular open-source DevOps platforms used by development teams to implement CI/CD. It provides a wide range of capabilities, including git repository management, pipelines, security scanning, issue tracking, release management, and more.

Some of the key features and benefits of GitLab include:

  • Built-in CI/CD – GitLab has a powerful native CI/CD engine. It allows creating pipelines directly from the GitLab UI or via YAML configuration files in the repo. Pipelines support parallel stages, job dependencies, custom scripts, and templating.
  • Kubernetes integration – GitLab provides first-class integration with Kubernetes for deploying containerized apps on clusters. Developers can leverage Auto DevOps to get a production-ready workflow out of the box.
  • Security scanning – GitLab includes many types of security scans like SAST, DAST, container scanning, and more. These can run at any stage of the pipeline to catch vulnerabilities early.
  • Project management – Each repository in GitLab is part of a full-featured project that includes issue tracking, milestones, labels, merge requests, and more for planning work.
  • GitLab CI/CD – GitLab provides a managed CI/CD service in the cloud to complement self-hosted instances. It allows running pipelines without provisioning your own Runners.
  • Integrations – GitLab integrates with popular developer tools like code editors, chat tools, notification services, artifact repositories, and more to create a unified DevOps platform.
  • Granular permissions – Role-based access control allows granting team members access to specific folders or settings in the GitLab instance. This improves security.
  • Open source – GitLab CE is open source, allowing free use and customization. The paid EE edition adds features like security scanning, compliance management, and support.
See also  How To Fix CVE-2022-0492- Privilege Escalation And Container Escape Vulnerabilities In Cgroups

We should know that one important security capability offered by GitLab is scan execution policies. This is important from this vulnerability context since this flaw has direct relations with GitLab scan policies. These policies allow a project’s security team to define required security scans that must run within CI/CD pipelines at the group or project level.

For example, a policy could require that dynamic application security testing (DAST) is performed anytime code is pushed to the develop branch. Static application security testing (SAST) could be mandated to run on merge requests into main.

Scan execution policies ensure best practices are enforced by directly injecting security scan jobs into the pipeline. Even if developers don’t include security testing in their .gitlab-ci.yml configuration, it will still occur due to the policy. This guarantees vulnerabilities are caught proactively.

Understanding CVE-2023-5009

CVE ID: CVE-2023-5009

Description: GitLab scan execution policies account takeover

CVSS Score: 9.6 (Critical severity)

Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N

CVE-2023-5009 stems from a vulnerability in GitLab’s scan execution policies feature. Scan execution policies allow security teams to define required security scans that must run within CI/CD pipelines as per organizational policy. However, a flaw in how these policies are processed can be exploited by an attacker to impersonate other users and run arbitrary pipelines as that user without authorization.

Successful exploitation of this vulnerability would enable the attacker to leverage the permissions of the impersonated user to access sensitive information, credentials, and source code or run malicious code on the system under the context of that user. This represents a critical severity vulnerability allowing account takeover and data access in affected GitLab instances.

The result is extremely serious as attackers could gain a foothold in private source code repositories or across a GitLab enterprise deployment. All organizations using vulnerable GitLab versions should apply fixes for CVE-2023-5009 urgently to prevent potential compromise of their entire DevOps toolchain.

GitLab Versions Vulnerable to CVE-2023-5009

According to GitLab’s security advisory, the vulnerability affects all versions starting from 13.12 before 16.2.7 and all versions starting from 16.3 before 16.3.4. So GitLab Enterprise Edition versions 13.12 and above are vulnerable if not patched to 16.2.7 or 16.3.4. Applying the latest upgrade is recommended.

  • All versions starting from 13.12 before 16.2.7
  • All versions starting from 16.3 before 16.3.4
See also  How to Fix CVE-2023-3269- StackRot Vulnerability in Linux Kernel?

How to Fix CVE-2023-5009?

GitLab has addressed the CVE-2023-5009 vulnerability by releasing patched versions 16.3.4 and 16.2.7. All users are strongly advised to upgrade to one of these latest versions as soon as possible to ensure their GitLab instance is secure.

For older versions prior to 16.2 that are no longer supported, GitLab has provided mitigations that can minimize exposure to this vulnerability. Disable either both or one of the feature’s direct file transfers and security policies.

Of course, upgrading to the fixed releases is strongly recommended rather than relying on mitigations alone. Upgrading can be performed using the official GitLab repositories, either Community Edition (CE) or Enterprise Edition (EE) based on what you have deployed.

How to upgrade GitLab to the latest version?

Time needed: 10 minutes.

The GitLab upgrade process depends on the installation methods followed in your organization. GitLab officially supports four different ways of the upgradation process:

1. Upgrade Using Package Manager
2. Upgrade to Specific Version
3. Manually Download and Install

Note: We are going to show this on a Ubuntu 23.04 machine. Images shown here are of Ubuntu.

If you want the installation or upgrade procedure for other platforms, don’t miss to hit this link.

Ubuntu
Debian
AlmaLinux
CentOS 7
OpenSUSE Leap
Amazon Linux 2
Amazon Linux 2023
Raspberry Pi OS
Docker
Kubernetes (Helm Chart)
Amazon Web Services (AWS)
Google Cloud Platform (GCP)
Microsoft Azure
Source

  1. Create a backup before upgrade

    It is highly recommended to have a full up-to-date backup before you begin.

  2. Install the prerequisites (Optional step- Apples only For first-time installation )

    Ensure you have these packages pre-installed on your server or Install them. It’s an optional step only applies to first-time installation of GitLab.

    sudo apt install tzdata curl ca-certificates openssh-server

    Install the GitLab prerequisites

  3. Add GitLab official repositories

    All GitLab packages are posted to the GitLab package server. Five repositories are maintained:

    1. gitlab/gitlab-ee: The full GitLab package that contains all the Community Edition features plus the Enterprise Edition ones.
    2. gitlab/gitlab-ce: A stripped-down package that contains only the Community Edition features.
    3. gitlab/unstable: Release candidates and other unstable versions.
    4. gitlab/nightly-builds: Nightly builds.
    5. gitlab/raspberry-pi2: Official Community Edition releases built for Raspberry Pi packages.

    If you have installed GitLab Community Edition or Enterprise Edition, then the official GitLab repository should have already been set up for you.

    Caution: GitLab repositories are not available on Ubuntu 22.04, you can’t use apt commands to install/upgrade. if you want to install, you should add the GPG key and repositories to install/upgrade using apt commands.

    Commands to import GPG Key:

    gpg_key_url="https://packages.gitlab.com/gitlab/gitlab-ce/gpgkey" curl -fsSL $gpg_key_url | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/gitlab.gpg

    Command to add repositories:

    sudo tee /etc/apt/sources.list.d/gitlab_gitlab-ce.list<<EOF
    deb https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/ focal main
    deb-src https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/ focal main
    EOF

    Command to update the repository database:

    sudo apt update

    Add GitLab official repositories

  4. Upgrade Using Package Manager

    For regular monthly upgrades, you can use your distribution’s built-in package manager:

    # Debian/Ubuntu
    sudo apt update && sudo apt install gitlab-ee

    # RHEL/CentOS 6 and 7
    sudo yum update && sudo yum install gitlab-ee

    # RHEL/CentOS 8
    sudo dnf upgrade && sudo dnf install gitlab-ee

    # SUSE
    sudo zypper refresh && sudo zypper install gitlab-ee

    Replace gitlab-ee with gitlab-ce if on the Community Edition.

    Upgrade Gitlab using Package Manager

  5. Upgrade to Specific Version

    To upgrade to a particular GitLab version, specify the intended fixed version during install/upgrade:

    # Debian/Ubuntu
    sudo apt install gitlab-ee=<version>

    # RHEL/CentOS 6 and 7
    sudo yum install gitlab-ee-<version>

    # RHEL/CentOS 8
    sudo dnf install gitlab-ee-<version>

    # SUSE
    sudo zypper install gitlab-ee=<version>

  6. Manually Download and Install

    You can also manually download and install the .deb or .rpm packages for a version from GitLab’s package repository:

    # Download package for intended version

    # Debian/Ubuntu
    sudo dpkg -i <package_name>

    # RHEL/CentOS 6 and 7
    sudo rpm -Uvh <package_name>

    # RHEL/CentOS 8
    sudo dnf install <package_name>

    # SUSE
    sudo zypper install <package_name>

  7. Verify the GitLab Version info

    After upgrading, it’s recommended to verify successful installation by checking the package version:

    # Debian/Ubuntu
    dpkg -i | grep gitlab

    # RHEL/CentOS 6 and 7
    rpm -q gitlab-ee

    # RHEL/CentOS 8
    dnf list --installed gitlab-ee

    # SUSE
    zypper search -s gitlab-ee

    The upgraded version should match your intended fixed release. You can also verify the installation fully completed without issues.

    Verify the GitLab Version info

All organizations using affected GitLab versions should schedule and prioritize upgrades that apply the fixes for CVE-2023-5009. GitLab has provided solid version guidance, mitigations, and upgrade instructions to support rapid remediation. Staying up to date with releases and promptly responding to critical security issues is vital for securing your GitLab instance.

Conclusion

CVE-2023-5009 represents a critical severity vulnerability in GitLab that could lead to account takeover through scan execution policies. Though details are technical, the result is serious – an attacker potentially gaining unauthorized access and control.

GitLab has responsibly disclosed this vulnerability and released patched versions 16.3.4 and 16.2.7. All users are strongly advised to upgrade to the latest available GitLab version as soon as possible.

Following security best practices like regular patching and upgrades is key to keeping your systems secure. For any DevOps tooling exposed to the internet, the risk of vulnerabilities is always present. But acting swiftly when issues are discovered helps minimize that risk dramatically.

So, in summary, check if your GitLab instance is vulnerable, review the mitigations if upgrading is not feasible currently, and try to update to the fixed release at your earliest opportunity. Taking action to fix CVE-2023-5009 and keeping GitLab hardened should be a priority for any organization relying on this powerful platform.

Leave a Reply

Your email address will not be published. Required fields are marked *