Critical Gitlab vulnerability let attackers take over accounts | Hacker News Reader

Critical Gitlab vulnerability let attackers take over accounts

bleepingcomputer.com

224 pointslelf43 comments

Seems to be a dupe of https://news.ycombinator.com/item?id=30872415

I actually recently moved over to using self-hosted Gitea, Nexus and Drone CI to cover most of the use cases that i needed GitLab for: https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-...

GitLab is actually pretty good: the UI is nice, the feature set is pretty complete and GitLab CI is still one of the best CI solutions that i've used and probably a noticeable step up from Jenkins, or at least the Jenkins instances that i've seen, but self-hosting it and keeping it up to date certainly takes a bit of care, especially if you ever want to have it be publicly available.

That's not to say that Gitea or any other piece of software couldn't have similar vulnerabilities, but rather that GitLab is a pretty large and complex piece of software that's also moving ahead rapidly, so situations like this are inevitable (also things like the EXIF vulnerability a while back https://gitlab.com/gitlab-org/gitlab/-/issues/327121). Perhaps even something as simple as basicauth in front of it can be helpful for cases like this (or just making things available only through a VPN, though that's likely to be too limiting in some cases, e.g. non-enterprise settings).

Edit: Actually, here's a question for the lovely people here: suppose that you want to self-host a platform with a web UI for working more easily with Git repos, something like GitHub, GitLab or other platforms like that, to collaborate on a project with some friends and/or like-minded strangers. What do you, a single person with a VPS and a bit of spare time pick for the most successful outcome? Or is the only viable advice nowadays: "Don't. Just use the cloud."?

For a small team, you could look at fossil: https://fossil-scm.org. It’s what SQLite team uses.

Oh hey, i think there was a post about Fossil here on HN a few days ago: https://news.ycombinator.com/item?id=30815693

It is most certainly a nice project and i'm all for alternatives to Git, but for many people having to give up their current tooling (e.g. IDE integrations, specific tools for graphical graphs, interactive staging of chunks, rebasing etc.) would probably be a non starter, since it's another source control system entirely, instead of a front-end/enhancement of what Git provides (e.g. ticketing, wikis, merge/pull request discussions, CI etc.).

Here's hoping that Fossil has a nice future ahead of it, there is certainly a number of projects that would benefit from it's relative simplicity when compared to Git!

Also their docs are pretty simple to understand: https://fossil-scm.org/home/doc/trunk/www/permutedindex.html

Though personally i really liked the more visual nature of SourceHut's page: https://sourcehut.org/

The IDE integrations bit is the most difficult thing for me; there was a fossil plugin for Jetbrains IDEs/IntelliJ, but it stopped being maintained, I maintained it a bit, but a large breaking change meant I didn't have enough time to keep it up, so I had to migrate away. I love fossil, but some things are difficult without a community around it developing the tools for it.

There is a VS Code extension that integrates fossil, and it works almost identically to the git integration, for the most part.

You can actually mirror a fossil repository to Git and use any of Git's downstream capabilities.

https://fossil-scm.org/home/doc/trunk/www/mirrortogithub.md

There was some muttering on the fossil site somewhere about supporting git format. Darcs was another thing like that, which was superior to git in most ways I can think of, while fossil has an anti-rebasing ideology that makes it unacceptable for certain types of git workflow. I don't know how that can be resolved while switching to git format. I do like integrating issue tracking with source control.

Unfortunately darcs suffered from the patch-of-doom problem, where if you were unlucky an exponentiation merge would kill all performance of your repository.

The darcs FAQ from 2012 reports it as still unfixed:

http://darcs.net/FAQ/Performance#is-the-exponential-merge-pr...

(Yes this was real, and yes we hit it. I liked the patch-centric darcs approach, but that was enough to make us migration to mercurial, then later git.)

The Tcl dev team uses it as well. They seem to like it.

Have you used it?

It's not for the general mass to say the least. You're better off using other focused products for each components than something that does everything in average ways.

The visual looks like they combined components from 20 years ago.

I use it every day for personal projects. Since I’ve been writing code for more than 20 years, the aesthetics aren’t as relevant to me. It’s a useful tool that works quite well. It’s not trying to win this year’s design competition.

Gitea is prob the best pick if you fancy a github-a-like. Hopefully we soon have forgefed/AP federation, to facilitate collaboration across servers. The intention is to make it a standard protocol for forges to share not just code but also the coordination/social parts, so a server can choose to allow outside contribution without registering or e-mail.

As soon as you get a Postgres server up and have some flow to keep your infra in source control (ansible+docker-compose/systemd goes a long way; they're a sane starting point for the unopionated mostly because of popularity), setting up new services is pretty straight-forward.

I did use nexus at work but tbh the official docker-registry container and a static webserver have proven sufficient for personal use.

Here's a decent run-down of alternatives for hosting a forge, it all comes down to preference: https://www.paritybit.ca/blog/choosing-a-self-hosted-git-ser...

> Or is the only viable advice nowadays: "Don't. Just use the cloud."?

For the people who really can't or won't self-host, I'd suggest at least looking at smaller providers rather than defaulting to big tech for everything.

It's surprisingly easy and efficient to run a Gitea instance behind a reverse proxy (Nginx et. al) plugged into Let's Encrypt. The built in sqlite3 DB method is plenty capable and snappy for a dozen projects and small team of people, it runs comfortably on the typical $5 cloud server and it offers a lot of capabilities (to the users and the Admin). Hobbyist groups like Disroot and non-profits like Codeberg are using it with much success, many folks find it easy to run their own personal instance within a few hours. Plenty of people share their build recipes online to just "clone and go" to DIY.

Second Gitea. Easy to deploy and maintain. Good enough for many people with intuitive interface.

I find self-hosting GitLab reasonably enjoyable. I use the Docker image (which contains the omnibus installation). It takes a ridiculous time to boot but I can only remember one time when upgrading wasn't as simple as pulling the new version and re-creating the container. Don't remember what went wrong though.

It's login-only, there's no other users, so I'm not too worried about security.

For anything public I use GitHub.

I've had several upgrade issues. Once several configuration settings were deprecated then removed... Silently. It was difficult to discover why it would no longer start. Another time a bunch of repositories only partially migrated, and appeared empty on clone.

Mostly it's the frequency of updates that's a pain, there are enough critical vulnerabilities that you have to stay on top of it.

I am the dog lying on a nail and occasionally whimpering at the moment though.

By far the easiest method, if you mostly trust your friends, is to forego the web UI and just use a directory on an SSH server. Do `mkdir project.git && cd project.git && git init --bare` and throw everybody's SSH keys into authorized_keys on the server, `git remote add origin user@server:project.git` on the client. The problems with this are that there's no privilege separation, i.e. everyone can do anything, there's no audit logs, and as mentioned previously there's no web UI. If everyone is actually expected to have a local copy of the repository, though, I don't see this as a huge issue. Issue tracking can be handled by a TODO file in the same or a separate repository.

When going this way, I can also recommend gitolite. It solves the whole privilege thing.

if you do self host, then please think about backups, especially for the stuff not in the repo (issues, wiki, whatever else)

I really like that Gitea is operationally simple and can run on a potato. If your team's fairly small, you can use SQLite to make it even simpler. GitLab's way, way too heavy.

Gitea + Nexus + Drone CI is what I've been using for a while and I really like it. I dumped GitLab after it became obvious they have no interest in serving the low end (ie: small users). I have no regrets. Gitea is a much better fit for me.

Maybe I'm bias because I've become accustomed to Gitea, but I really feel like Gitea augments my workflow while GitLab and GitHub are trying to usurp my workflow. I use GitHub, but only for push mirroring when I want to use something like Cloudflare Pages / Functions that do GitOps style managed deployment.

As for an extra layer of auth, I think Cloudflare Access makes a lot of sense for small users. Put everything behind Cloudflare, use split horizon DNS for LAN access, and rely on Cloudflare to pre-auth all users before they can connect via the internet.

GitLab is a prime example of "do many things and do them averagely". Sure it got many features but there are bugs and each feature isn't as polished as other isolated apps and it takes huge resource.

How it turned out to be a unicorn, I guess good sales and not by the technical advantage.

If you're self-hosting gitlab-ce (which should really be open to internal traffic only) and want one more layer of protection from all this stuff, it's easy to throw it behind http basic auth. In your gitlab.rb:

nginx['custom_gitlab_server_config'] = "auth_basic 'Restricted';\n auth_basic_user_file /etc/gitlab/.htpasswd;\n location ^~ /.well-known { root /var/www/letsencrypt; auth_basic off;}"

A different comment thread recommending http basic auth: https://news.ycombinator.com/item?id=29761966

Do internal hosted versions not have auth built in ?

It keeps the riff-raff away when a new gitlab 0day appears in some obscure public/guestuser visible API

A more standard way is to use `auth_request`, which passes every incoming request to some auth server to get a yes/no response. And this service can be as simple or complicated as you'd like.

FYI that Gitlab rotates their package signing GPG key every two years and default yum-cron won't auto-update their packages until the new key is manually approved.

If you're going to hardcode a password like this (and I think this is one of the rare situations where it could actually make sense to do it) you need to also ensure that this hardcoded password:

1. Can't be used to login, ever.

2. Can't be used as an actual password.

Then what’s the use of the password?

It looks like it was used for tests. I don't know how it would escalate to use on a production system, but the commit for the fix is here:

https://gitlab.com/gitlab-org/gitlab/-/commit/e2fb87ec5d4e23...

Oh someone used the test fixture in lib/gitlab/auth/o_auth/user.rb

This is why test code should be impossible to import in non-test code. It should be part of the build infrastructure for the language.

From what I gathered, it was used as a placeholder for user accounts that were created via federated login. So the user would never actually be logging in to Gitlab directly with a password.

Why not just randomly generate it each time, then?

Maybe there are auto tests, which would have been simpler to create, if the password was static

The classic hardcoded password

I got this email for an account that uses the public gitlab.com service.

My take was this is self hosted gitlab instances, correct?

Not only, some users in our organization have received an email announcing them the password reset and we are using gitlab.com.

14.9.2, 14.8.5, 14.7.7 are the patched versions - saved you a click :)

If you update blindly to these patch versions without actually clicking you may not be the best security operator

Reply on news.ycombinator.com