It's always a little unexpected when the security vulnerabilities are in the tools we use to build software instead of just in the software. I suppose it's a class of supply chain vulnerability.
In this particular class of impersonation problem (the Gitlab issue is about running a pipeline as another user), sometimes I find it unnerving how much an attacker could accomplish in a software company by being able to impersonate an arbitrary Slack user. We are taught to be cautious around incoming email, but I've yet to see a security training around "how do you know that your instant messages are genuine."
This happened to us using Flowdock (a Slack competitor), they had a main DB failure, and when a new one was promoted the state was bad, and so "new" employees from another company started appearing in our organisation replacing our own employees, they could then read our private messages and access our rooms.
It was really hard for me to find a responsible from Flowdock/Broadcom/Rally Software/CA Technologies to report the leak, but in the end they killed the servers until they got the issues under control.
Because of this I mostly share encrypted files over chat, using OpenPGP, but the user experience is terrible for most :(
In fairness, it was file extension spoofed exe made to look like a PDF file. When sent to someone who frequently downloads and opens PDFs as part of their job, it would be a very easy mistake to make, especially for the unaware to this attack vector.
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.
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.
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.
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 . There's probably just as many in their hosted product, but we don't hear about them because they're fixed quietly.
> 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.
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.
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.
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.
There's now a single codebase containing both enterprise and FOSS. Enterprise features live in the `ee/` subfolder of the repository. This allows them to share code. (EE used to be a (visible-source) fork of CE, but the repos got merged like a year or so ago).
This comment boggles my mind. There are hundreds of developers just employed by gitlab, and likely many thousands of contributors and a multiple of active users voicing their (probably often contradictory) wishes. You want to track this in a system, and their core product includes exactly such a tool that allows people to have precisely this kind of input and transparency. You can add an issue, add a me-too thumbs up (vote), emoticons, comments etc. You will get updated via mails on the progress of the issue, etc.
The customer got a nice reply saying that the exact concern is being worked on, how and where to signal interest, track progress, etc. What did you expect, what more can you do? What would honor mean?
Have you ever worked in software? Do you know have many issues production code has? 50,000 open issues is nothing for a project of this size. Do you have any idea how much issues are closed daily? Gitlab is very actively using their issuetracker and sharing their progress with the world. Try finding a company with as much transparacy as Gitlab.
> In practice, customers can also make requests via private support tickets.
Yep. Sometimes, it can also be helpful to ask publicly in a forum topic or issue and link that in the support ticket, asking for prioritized support.
> I’ve seen GitLab determine priority of an issue based partially on demand from paying customers.
Correct. You might have seen team members commenting with customer requests into issues and epics. While we at GitLab cannot share customer names and other confidential data, the feature request itself is public and increases transparency.
Requests are triaged using automation and AI, and responsible teams include the reviews in their planning. 
Issues (and related MRs) are targeting milestones. Since we at GitLab work in iterations and smaller changes to release features faster, epics help plan and group the issues. Roadmaps and boards are used by product managers, too.   Example roadmap filtered by the CI section 
Every stage, group, feature has labels applied, which allows the creation of specific filters. For example, "Category:Code Suggestions" as label filter 
Additional helpers are available in the handbook, for example the "Features by group" overview  which shows the feature maintainers in the section, stage, group, product and engineering managers, etc.
Customers can open support tickets, too.  Opening a public issue is encouraged so other community members can engage and collaborate. Often, a workaround or fast solution is unveiled because of collaboration and transparency.
When in doubt whether it is a bug or feature, or asking for (troubleshooting) help, you are welcome to join our community forum or Discord.  I'm mostly active on the forum myself. 
Microsoft has a track record for delaying fixes and marking important issues as “not a bug”, so I’m less impressed with their security.
As terrible a corporation as Oracle is, their security response team has been one of the most effective and fast-paced I’ve ever reported to. With that said, they pay nothing to researchers, so Gitlab certainly shows they care more about security.