Security breaches keep sneaking up on even the most robust platforms. GitLab, the beloved DevOps tool, recently grappled with an alarming vulnerability: CVE-2023-4018. This flaw enabled unauthorized users to create model experiments in public projects due to improper permission checks. Let's break down what happened, explore a simplified code example of the bug, and explain what you need to do to stay safe.

GitLab version 16.3 up to (but not including) 16.3.1

Because of insufficient permission validation, any user was able to create machine learning model experiments within public projects—even if they were not supposed to.

Why Does This Matter?

Model experiments are typically reserved for authorized team members, as they can expose sensitive workflows, resource usage, or even serve as a vector for further attacks. Allowing anyone to create experiments can mess up project data, consume resources, or slip malicious code or data into your project pipeline.

then you're vulnerable.

Fixes:

Check your GitLab version with this command

gitlab-rake gitlab:env:info

How Did This Happen? (A Simplified Code Look)

Let’s imagine a simplified Ruby controller in GitLab, handling requests to create a new model experiment:

def create_experiment
  project = Project.find(params[:project_id])
  # MISSING: should check user permissions here!
  experiment = project.experiments.create(
    name: params[:name],
    description: params[:description]
  )
  render json: experiment
end

Notice what’s missing? There’s no check to see if the user actually has permission to create an experiment.

A safer approach

def create_experiment
  project = Project.find(params[:project_id])
  # Check if user can create experiments!
  unless current_user.can?(:create_experiment, project)
    return render status: :forbidden, json: {error: "Unauthorized"}
  end

  experiment = project.experiments.create(
    name: params[:name],
    description: params[:description]
  )
  render json: experiment
end

In the bugged logic, anyone—logged in or not—could POST to the endpoint and create an experiment in any public project.

Let’s see a hypothetical exploitation using curl

curl -X POST "https://gitlab.example.com/api/v4/projects/123/model_experiments"; \
  -H "Content-Type: application/json" \
  -d '{"name":"evil_experiment","description":"Stealing your data"}'

If the project is public, this would usually succeed—even if you were just an anonymous user!

GitLab Security Advisory:

GitLab Critical Security Release: 16.3.1, 16.2.5

NVD CVE Entry:

CVE-2023-4018 at NIST NVD

GitLab Issue Tracker (confidential):

GitLab issue #424326

Update immediately to at least version 16.2.5 or 16.3.1.

3. Audit your public projects’ model experiments for anything odd, just in case someone abused the bug before you patched.

Conclusion

CVE-2023-4018 is a reminder that even with open source and major platforms, permission checks are critical. Whether you’re running your own GitLab instance, or using someone else’s, always keep up to date with security upgrades. Small mistakes in code can lead to big leaks.

Stay alert, keep your patches applied, and never assume public means safe!

Timeline

Published on: 09/01/2023 11:15:00 UTC
Last modified on: 09/07/2023 18:22:00 UTC