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
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
-
UserA
createsProjectA
and addsUserB
as maintainer -
UserA
creates a specificrunnerA
forProjectA
and allows it to be assigned to other projects -
UserB
creates a public project and enablesrunnerA
on it -
UserB
is removed fromProjectA
THE ISSUE: -
UserB
can access current and future private projects from the endpoint/runners/:id/jobs
because they are still considered owner ofrunnerA