Job information is leaked to unauthorized users via the Runner Jobs API endpoint

HackerOne report #1092199 by vaib25vicky on 2021-02-01, assigned to @rchan-gitlab:

Report | How To Reproduce

Report

Summary

The past report gitlab-foss#53032 (closed) is not considered a security issue because
as per this gitlab-foss#53032 (comment 110938617)

Even if we restricted that endpoint, it wouldn't matter because who owns the runner will still be able to access private repo source code, jobs handled by the runner, etc.

But I've found that this is a valid security issue in different cases such as

  • Owner of the runner user A , enabled specific runner to be used by other maintainers of the project
  • user B add the runner to their project, now as mentioned this is not a security issue because user B knows that user A owns runner and they can access the Jobs/Pipelines/namespace etc.
  • BUT this becomes a security issue when the user A removes the user B from the project then user B can also access the endpoint /runners/:id/jobs and access user A private projects jobs/Pipelines/namespace.
  • In this case user B is not the owner of the runner

There should be access control on the endpoint /runners/:id/jobs. There may be more such cases.

Impact

Private Projects' Jobs/Pipelines/namespace etc are leaked to Specific Runner Jobs API endpoint due to missing access control on the endpoint /runners/:id/jobs

How To Reproduce

  1. UserA creates ProjectA and adds UserB as maintainer
  2. UserA creates a specific runnerA for ProjectA and allows it to be assigned to other projects
  3. UserB creates a public project and enables runnerA on it
  4. UserB is removed from ProjectA
    THE ISSUE:
  5. UserB can access current and future private projects from the endpoint /runners/:id/jobs because they are still considered owner of runnerA
Edited by Laura Montemayor