5 ms·

This is the original issue thread from two months ago: https://gitlab.com/gitlab-org/gitlab/-/issues/417594 https://gitlab.com/gitlab-org/gitlab/-/issues/41759

by gizmo 3y ago

This is the original issue thread from two months ago: https://gitlab.com/gitlab-org/gitlab/-/issues/417594 https://gitlab.com/gitlab-org/gitlab/-/issues/417594 And the root cause seems to be... > Change your git config and include username of the your victim that is, > git config --global user.name "victim" Oops.

prmoustache 3y ago
This is not the root cause but the way to exploit it imho. The root cause was that the pipeline process would reuse CI tokens that gives access to other repos/projects just by being added as member on someone else's repo and being formally marked as user in a commit.
- plagiarist 3y ago
  Wow. That kind of decision does not inspire confidence in the product.
  - hoseja 3y ago
    What is the vulnerability here? Being an asshole to a co-member on a project? What I'm saying is, this seems like a place of mutual trust, no apparent reason to be especially hardened.
    - tyingq 3y ago
      No, it works cross project, with no specific need for the victim to do anything dumb. And the attacker needs no rights to the victim target repo. You end up with an active CI_JOB_TOKEN that impersonates the victim. It's pretty bad.
    - kelnos 3y ago
      No, the issue is that a random attacker can create a group, and add the victim to the group themselves, and that gives them access to the victim's private repos, albeit through a pretty convoluted execution path.
  - tyingq 3y ago
    It's specifically exploiting a bad choice made in the SAST analyzer part of the project, which is kind of interesting...as you would think that the security-minded people work on that tool. That pattern seems kind of predictable too. You have the main product, with the main team, that probably understands things like how they use tokens for CI pretty well. Then, as the product grows, you get satellite teams to work on features outside the core. Things like this SAST analyzer, GitLab pages, Gitlab Wiki, etc. They don't have the same deep understanding of the core product. So they probably do a lot of trial and error until something works. So I guess one lesson for the main product team is that they need to expose apis and data to these peripheral product teams as if those teams were a third party...don't give them automatic access to everything.
    - zx8080 3y ago
      Would someone share some details on why SAST mentioned in this thread, for those who are not familar with the Gitlab architecture design and product decisions. Thanks.
      - tyingq 3y ago
        Their product includes a static code analysis tool you can run in ci/cd pipelines, triggered by the existence of some files in your repo. It's the entry point for this exploit. Something the attacker abuses to get rights they shouldn't have. The victim doesn't have to use it at all.
    - plagiarist 3y ago
      I think that lesson is a great takeaway. I don't think it should have been possible to generate access levels equal to the user without their direct input (for example, on a specific "generate access token" page). Then a satellite team requesting that ability hopefully would have raised red flags with the main team, if that's how they're operating.
    - acdha 3y ago
      I’ve gotten a lot of value from GitLab but I have to say that the frequent security issues significantly undercut the messaging about their product being a security solution. I’ve gotten the impression that they’re trying to expand rapidly to have more points where they can offer a feature which GitHub doesn’t have, which is certainly understandable but also gives the impression that their teams are overstretched and probably burning out. It’s pretty common to encounter an issue which has been open for years without progress despite a fair amount of customer interest.

by gizmo 3y ago

prmoustache 3y ago

This is not the root cause but the way to exploit it imho. The root cause was that the pipeline process would reuse CI tokens that gives access to other repos/projects just by being added as member on someone else's repo and being formally marked as user in a commit.

plagiarist 3y ago
Wow. That kind of decision does not inspire confidence in the product.
- hoseja 3y ago
  What is the vulnerability here? Being an asshole to a co-member on a project? What I'm saying is, this seems like a place of mutual trust, no apparent reason to be especially hardened.
  - tyingq 3y ago
    No, it works cross project, with no specific need for the victim to do anything dumb. And the attacker needs no rights to the victim target repo. You end up with an active CI_JOB_TOKEN that impersonates the victim. It's pretty bad.
  - kelnos 3y ago
    No, the issue is that a random attacker can create a group, and add the victim to the group themselves, and that gives them access to the victim's private repos, albeit through a pretty convoluted execution path.
- tyingq 3y ago
  It's specifically exploiting a bad choice made in the SAST analyzer part of the project, which is kind of interesting...as you would think that the security-minded people work on that tool. That pattern seems kind of predictable too. You have the main product, with the main team, that probably understands things like how they use tokens for CI pretty well. Then, as the product grows, you get satellite teams to work on features outside the core. Things like this SAST analyzer, GitLab pages, Gitlab Wiki, etc. They don't have the same deep understanding of the core product. So they probably do a lot of trial and error until something works. So I guess one lesson for the main product team is that they need to expose apis and data to these peripheral product teams as if those teams were a third party...don't give them automatic access to everything.
  - zx8080 3y ago
    Would someone share some details on why SAST mentioned in this thread, for those who are not familar with the Gitlab architecture design and product decisions. Thanks.
    - tyingq 3y ago
      Their product includes a static code analysis tool you can run in ci/cd pipelines, triggered by the existence of some files in your repo. It's the entry point for this exploit. Something the attacker abuses to get rights they shouldn't have. The victim doesn't have to use it at all.
  - plagiarist 3y ago
    I think that lesson is a great takeaway. I don't think it should have been possible to generate access levels equal to the user without their direct input (for example, on a specific "generate access token" page). Then a satellite team requesting that ability hopefully would have raised red flags with the main team, if that's how they're operating.
  - acdha 3y ago
    I’ve gotten a lot of value from GitLab but I have to say that the frequent security issues significantly undercut the messaging about their product being a security solution. I’ve gotten the impression that they’re trying to expand rapidly to have more points where they can offer a feature which GitHub doesn’t have, which is certainly understandable but also gives the impression that their teams are overstretched and probably burning out. It’s pretty common to encounter an issue which has been open for years without progress despite a fair amount of customer interest.