Skip to content

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.

permissions_doc.png

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

  1. 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}"

  2. Invite userB (attacker) to your project with Guest role.

    project_members.png

  3. 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  
                            }  
                          }  
                        }  
                      }  
                    }  
                  }  
                }  
              }  
            }  
          }  
        }  
      }  
    }  
  }  
}

  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!

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

Edited by Nikhil George