We use gitlab ultimate at my work, I’m the main admin of the instance. Like 2 weeks ago when there was the cvss 10 vuln, gitlab sent us a .patch file to apply to the instance instead of releasing a new minor cause they didn’t wanna make the vuln public yet. I guess that’s coordinated disclosure, but I still found that remarkably jank.
deleted by creator
Yum upgrade. Nightly. Since about v9.
bruh, feels like gitlab has security update every other day, it’s some bullshit even for a project this size. And who knows how many 0-days are around.
I’ve been hanging a version back for a while now. Although my instance isn’t public, it’s ridiculous how many CVEs I have dodged by not updating. SolarWinds all over again.
And their license cost increases at almost the same rate.
No it doesn’t. Gitlab’s pricing has been pretty stable, with one increase in the premium tier in the past six years ($19 --> $29 per user per month).
There were more increases, they just changed the tier names and billing terms, so it’s somewhat hard to find historical information of previous prices. Our company ditched it after the 52% increase in 2023, especially because we were still adjusting to the price increase from 2021, which for us was $6 per user per month. I think in 2018 or 2019 it was $3 per user per month, so there must have been another increase that happened between 2018 and 2021. This was all for self hosted, so we had the additional cost of hardware and to maintain the services.
I really wanted to support GitLab, but the price simply became too much to justify.
Check gitlab-rails/production_json.log for HTTP requests to the /users/password path with params.value.email consisting of a JSON array with multiple email addresses.
Jesus Christ. Their frontend was sending a list of recipients to the backend. That’s an intern developer level of fuck up, in their login system, no less.
If this got past them, it’s a sign of deep problems.
Can you explain in a bit more detail what you understand was happening?
Gitlab has a backend, which runs on a server, and a frontend, which runs in all the user’s browsers. When the user does anything it sends some network requests to the backend in order to save the changes the user has made, send the necessary emails or create a session, etc.
The thing with this architecture is the backend and frontend are effectively separate apps. Also as the frontend is running remotely on the attacker’s computer the attacker can change it to behave however they want. The backend can’t trust the frontend to “do the right thing”, ever. The backend needs to assume the frontend will do every bad and silly thing possible, and treat anything coming from the frontend with maximum suspicion.
So you simply can’t allow the frontend code to provide a list of email addresses to send an email to, because it’ll allow the attacker to send emails to anywhere. Where the email goes to needs to be determined by the backend. The frontend should only be concerned with hiding and showing stuff in the UI, and pretty much all intelligence and business logic needs to reside on the server where we control the code and environment. A good understanding of the roles and responsibilities of the front vs back is a fundamental concept and if the developer hasn’t grasped this then they’re going to introduce security problems everywhere they go.
This is one of many pitfalls of the “frontend + backend” architecture. I vastly prefer to build monoliths instead.
Not the commenter but it seems like the parameters of the HTTP Get/Post weren’t protected/checked. The API was likely something like: Email to reset: string(email account to reset) But it accepted something like: [string(email account to reset), string (email to which the reset mail is sent to)]
Little Bobby Tables? Or would that be an XHR attack?
Bobby table, this, buffer overflow… Are all similar in spirit.
Bobby table is a way for hiding the malicious SQL query after a normal query (in that case after the select with “Bobby” you inject the malicious drop table)
In this case after the normal email (that normally would serve for both identifying the user and for the mail to send the recovering mail), the attacker sends two mails, the first is fo identifying the user the second to send the recovering mail
In the case of buffer overflow you inject malicious code after normal(-ish) data
It’s not an XHR attack since for the mail recovery workflow you don’t need an authenticated session.
To be a bit more compassionate to the developers, this is probably some dynamic typing problem. Probably ruby is “smart” into understand that an array can contain strings after all… So an array of strings is as good as a string… But here we go into static vs dynamic typing… And it’s a bit of religious war (fun fact in 2011 i was advocating with Guido Van Rossum in having at least an optional static typing check in Python - at the time the discussion was how to make python faster/compiled - and he was borderline mocking me 😅 and few years after pytypes but still no compilation at horizon 😂)
Thanks for the explanation, my friend!
My problem is that I am a hopeless generalist (which basically means I invariably find myself in support positions rather than what I actually should be doing), and IT is an endless jungle. I’m too curious for my own good.
Holy shit, that’s the rookiest mistake.
