Guest project member can access log of jobs with enabled debug logging
HackerOne report #1113405 by jimeno
on 2021-02-28, assigned to @ngeorge1:
Report | Attachments | How To Reproduce
Report
Summary
Guest project member can access log of jobs with enabled debugging after some, presumably, caching period. Official documentation says they can't.
GitLab official docs say:
With restricted access to debug logging, only users with developer or higher permissions can view job logs when debug logging is enabled with a variable in:
- The .gitlab-ci.yml file.
- The CI/CD variables set within the GitLab UI.
They provide an example of enabling the debug mode too.
To enable debug logs (traces), set the CI_DEBUG_TRACE variable to true:
job_name:
variables:
CI_DEBUG_TRACE: "true"
I decided to test caching mechanisms in GitLab after reading #289944 (closed), which is another caching bug at GitLab that was rewarded and fixed.
Steps to reproduce
-
As userA (victim) create a project and enable GitLab CI for it by adding the following YAML file to it.
image: alpine:latest variables: FOO: bar stages: - test dummy: variables: CI_DEBUG_TRACE: "true" stage: test script: - echo "${FOO}"
-
Invite userB (attacker) to your project with Guest role.
-
As your victim user, browse to the GraphQL explorer and run the following query in order to find the Job ID. Please note we are only doing this step to find job's ID. In a real world scenario, attacker could omit this step by bruteforcing it (incremental, decimal number). Please, remember to replace
fullPath
with yours (project_author/project_name
).query infogathering { project(fullPath:"naaytesting2/proje") { pipelines { edges { node { id stages { edges { node { name groups { edges { node { name jobs { edges { node { name detailedStatus { detailsPath } } } } } } } } } } } } } } }
-
Grab the Job ID from the
detailsPath
value in the response. In my case it looks like/naaytesting2/proje/-/jobs/1061991036
-->1061991036
. -
Wait for at least 2 minutes. As your attacker user, build the final attack URL by replacing the placeholders in this URL:
https://gitlab.com/AUTHOR/PROJECTNAME/-/jobs/JOBID/artifacts/download?file_type=trace
. In my case, the final URL looked likehttps://gitlab.com/naaytesting2/proja/-/jobs/1061991036/artifacts/download?file_type=trace
. -
Download and open the
job.log
file. -
If victim tries to browse to the job directly, for example at
https://gitlab.com/naaytesting2/proje/-/jobs/1062011620
they get an insufficient permissions error.[redacted]
Impact
Roles aren't respected when accessing jobs with debug logging enabled.
Examples
Attached you will find a test repository. However, I don't think this is helpful.
What is the current bug behavior?
Roles aren't respected and Guest members can access jobs they aren't supposed to access.
What is the expected correct behavior?
Guest and Reporter members get a 403/404 response when trying to access jobs they aren't supposed to access.
Relevant logs and/or screenshots
Please, find a detailed step by step reproduction attached to this report.
[redacted]
Output of checks
This bug happens on GitLab.com
Results of GitLab environment info
N/A. Tests performed 2020/02/28 19:00-20:30 Madrid time.
Impact
Roles aren't respected when accessing jobs with debug logging enabled.
Attachments
Warning: Attachments received through HackerOne, please exercise caution!
- [redacted]
- project_members.png
- permissions_doc.png
- [redacted]
Technical proposal
Projects::ArtifactsController#download
only checks the read_build
policy to determine whether a user has access. When file_type
is trace
and build.debug_mode?
, #download
should additionally apply the read_build_trace
policy