Skip to content
GitLab Next
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GitLab FOSS GitLab FOSS
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 0
    • Merge requests 0
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.org
  • GitLab FOSSGitLab FOSS
  • Issues
  • #21167
Closed
Open
Created Aug 22, 2016 by Stan Hu@stanhuOwner

Issue Boards leak private label names and descriptions

  • Title: Boards leak private label names and desciptions
  • Types: Information Disclosure
  • Link: https://hackerone.com/reports/162147
  • Date: 2016-08-22 06:15:23 -0700
  • By: jobert

Details:

Vulnerability details

In anticipation of today's release, I took a look at the new boards feature - which, unrelated to this report, is awesome! There turns out to be an IDOR vulnerability when creating a list based on a label. An attacker can create a list with a label ID that belongs to a private repository. This leaks the name and description of the label to the attacker.

Proof of concept

  • Create a new, private repository
  • In the created repository, create a new label - lets assume it has label ID 1
  • Create another repository, doesn't matter if it's a private or public repository, and doesn't have to be scoped under the same namespace
  • In the created repository, create another new label - lets assume it has label ID 2
  • Go to the board of the repository created in step 3, and intercept your network traffic
  • Click the label created and notice similar to the one below being sent to the GitLab instance:

Request

POST /jobertabma/test/board/lists HTTP/1.1
Host: gitlab-instance
...

{"list":{"label_id":2}}

Response

HTTP/1.1 200 OK
...

{"id":3,"list_type":"label","position":1,"title":"super secret title","label":{"id":1,"title":"super secret title•Œ","color":"#428BCA","description":null,"priority":null}}
  • In the request, change the label_id to 1, or any other label ID that doesn't belong to you and forward the request.
  • Refresh the board page, notice the created list - it contains the label name and description

Fix

This is a very ugly solution, but I just wanted to include it to point you to the vulnerability LoC. Line 18 (or 20, after the fix), creates a List object without making sure the provided label_id belongs to the project.

diff --git i/app/services/boards/lists/create_service.rb w/app/services/boards/l
index 5cb408b..630b05a 100644
--- i/app/services/boards/lists/create_service.rb
+++ w/app/services/boards/lists/create_service.rb
@@ -15,6 +15,8 @@ module Boards
       end

       def create_list_at(position)
+        params[:label_id] = project.labels.find(params[:label_id]).id
+
         board.lists.create(params.merge(list_type: :label, position: position))
       end
     end
Assignee
Assign to
Time tracking