**[HackerOne report #1113405](https://hackerone.com/reports/1113405)** by `jimeno` on 2021-02-28, assigned to @ngeorge1: [Report](#report) | [Attachments](#attachments) | [How To Reproduce](#how-to-reproduce) ## Report ##### Summary Guest project member can access log of jobs with enabled debugging after some, presumably, caching period. Official [documentation](https://docs.gitlab.com/ee/user/permissions.html) says they can't.  GitLab official [docs](https://docs.gitlab.com/ee/ci/variables/README.html#restricted-access-to-debug-logging) 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](https://docs.gitlab.com/ee/ci/variables/README.html#enable-debug-logging) of enabling the debug mode too. > To enable debug logs (traces), set the CI_DEBUG_TRACE variable to true: ```yml job_name: variables: CI_DEBUG_TRACE: "true" ``` I decided to test caching mechanisms in GitLab after reading https://gitlab.com/gitlab-org/gitlab/-/issues/289944, which is another caching bug at GitLab that was rewarded and fixed. ##### Steps to reproduce 1. As userA (victim) create a project and enable GitLab CI for it by adding the following YAML file to it. ```yaml image: alpine:latest variables: FOO: bar stages: - test dummy: variables: CI_DEBUG_TRACE: "true" stage: test script: - echo "${FOO}" ``` 2. Invite userB (attacker) to your project with Guest role.  3. As your victim user, browse to the [GraphQL explorer](https://gitlab.com/-/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`). ```graphql query infogathering { project(fullPath:"naaytesting2/proje") { pipelines { edges { node { id stages { edges { node { name groups { edges { node { name jobs { edges { node { name detailedStatus { detailsPath } } } } } } } } } } } } } } } ``` 4. Grab the Job ID from the `detailsPath` value in the response. In my case it looks like `/naaytesting2/proje/-/jobs/1061991036` --> `1061991036`. 5. 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 like `https://gitlab.com/naaytesting2/proja/-/jobs/1061991036/artifacts/download?file_type=trace`. 6. Download and open the `job.log` file. 7. 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](https://h1.sec.gitlab.net/a/32f812f4-0c20-4223-9b0e-828f47799c01/project_members.png) * [permissions_doc.png](https://h1.sec.gitlab.net/a/a3040412-8e95-4fe4-8641-5ecca1361247/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