4 ms·

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-min

by 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.
- GauntletWizard 3y ago
  I think a lot of that is that they are security minded, open source, and Gitlab is loud about their vulnerabilities, as part of that ethos. GitHub enterprises, the on-prem version of their product, has plenty of vulnerabilities [1]. There's probably just as many in their hosted product, but we don't hear about them because they're fixed quietly. [1] https://www.cvedetails.com/vulnerability-list/vendor_id-11914/product_id-81111/Github-Enterprise-Server.html https://www.cvedetails.com/vulnerability-list/vendor_id-1191...
  - acdha 3y ago
    It’s not just that but, yes, I don’t want to over-weight it due to visibility. It just feels like they’re over-stretched, especially since non-security issues are exactly the same.
ttegloma 3y ago
> which is kind of interesting...as you would think that the security-minded people work on that tool. I work in security at a company with similar tools and unfortunately I think this is an incorrect assumption. Security people aren’t necessarily good developers, and good developers aren’t necessarily good security people. And being “security minded” really isn’t good enough. At the end of the day, the team building the product has the first and foremost priority of launching the product. This always means cutting corners, or not going as deep as might be necessary for certain issues like this, even if they are “security minded”. You really have to have a checks-and-balances on this by having a dedicated security team that has a priority of first and foremost not allowing security vulnerabilities to make it into launched products. I’m not sure if GitLab has that or not, I’m just saying that wouldn’t make any assumptions about the security posture of a feature just because it’s a “security feature”. If anything I’d be more wary of them, because in my experience there actually can be an attitude of “my shit doesn’t stink” among people developing security products.
- tyingq 3y ago
  I guess, though they work on an SAST scanner that identifies problems pretty similar to this one, untrusted input, "confused deputy", etc.

by tyingq 3y ago

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.

GauntletWizard 3y ago
I think a lot of that is that they are security minded, open source, and Gitlab is loud about their vulnerabilities, as part of that ethos. GitHub enterprises, the on-prem version of their product, has plenty of vulnerabilities [1]. There's probably just as many in their hosted product, but we don't hear about them because they're fixed quietly. [1] https://www.cvedetails.com/vulnerability-list/vendor_id-11914/product_id-81111/Github-Enterprise-Server.html https://www.cvedetails.com/vulnerability-list/vendor_id-1191...
- acdha 3y ago
  It’s not just that but, yes, I don’t want to over-weight it due to visibility. It just feels like they’re over-stretched, especially since non-security issues are exactly the same.

ttegloma 3y ago

> which is kind of interesting...as you would think that the security-minded people work on that tool. I work in security at a company with similar tools and unfortunately I think this is an incorrect assumption. Security people aren’t necessarily good developers, and good developers aren’t necessarily good security people. And being “security minded” really isn’t good enough. At the end of the day, the team building the product has the first and foremost priority of launching the product. This always means cutting corners, or not going as deep as might be necessary for certain issues like this, even if they are “security minded”. You really have to have a checks-and-balances on this by having a dedicated security team that has a priority of first and foremost not allowing security vulnerabilities to make it into launched products. I’m not sure if GitLab has that or not, I’m just saying that wouldn’t make any assumptions about the security posture of a feature just because it’s a “security feature”. If anything I’d be more wary of them, because in my experience there actually can be an attitude of “my shit doesn’t stink” among people developing security products.

tyingq 3y ago
I guess, though they work on an SAST scanner that identifies problems pretty similar to this one, untrusted input, "confused deputy", etc.