[HN Gopher] Critical Gitlab vulnerability lets attackers take ov...
___________________________________________________________________
Critical Gitlab vulnerability lets attackers take over accounts
Author : lelf
Score : 176 points
Date : 2022-04-01 15:11 UTC (7 hours ago)
(HTM) web link (www.bleepingcomputer.com)
(TXT) w3m dump (www.bleepingcomputer.com)
| rob-olmos wrote:
| 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.
| chaz6 wrote:
| I got this email for an account that uses the public gitlab.com
| service.
| showerst wrote:
| 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;}"
| Naac wrote:
| A different comment thread recommending http basic auth:
| https://news.ycombinator.com/item?id=29761966
| paxys wrote:
| 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.
| czbond wrote:
| Do internal hosted versions not have auth built in ?
| 0x0 wrote:
| It keeps the riff-raff away when a new gitlab 0day appears in
| some obscure public/guestuser visible API
| moepstar wrote:
| 14.9.2, 14.8.5, 14.7.7 are the patched versions - saved you a
| click :)
| [deleted]
| kfrzcode wrote:
| If you update blindly to these patch versions without actually
| clicking you may not be the best security operator
| nightpool wrote:
| Seems to be a dupe of
| https://news.ycombinator.com/item?id=30872415
| czbond wrote:
| My take was this is self hosted gitlab instances, correct?
| Chafouin wrote:
| Not only, some users in our organization have received an email
| announcing them the password reset and we are using gitlab.com.
| ichugwindex wrote:
| The classic hardcoded password
| KronisLV wrote:
| 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."?
| brimble wrote:
| 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.
| johnny22 wrote:
| if you do self host, then please think about backups,
| especially for the stuff not in the repo (issues, wiki,
| whatever else)
| Hello71 wrote:
| 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.
| fuzzy2 wrote:
| When going this way, I can also recommend gitolite. It solves
| the whole privilege thing.
| fuzzy2 wrote:
| 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.
| codebje wrote:
| 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.
| anticrisis wrote:
| For a small team, you could look at fossil: https://fossil-
| scm.org. It's what SQLite team uses.
| KronisLV wrote:
| 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/
| throwaway81523 wrote:
| 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.
| thunderbong wrote:
| 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
| brobdingnagians wrote:
| 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.
| sigzero wrote:
| The Tcl dev team uses it as well. They seem to like it.
| 3np wrote:
| 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.
| ancientsofmumu wrote:
| 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.
| jaywalk wrote:
| 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.
| diarrhea wrote:
| Then what's the use of the password?
| mikeryan wrote:
| 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...
| mikeryan wrote:
| Oh someone used the test fixture in
| lib/gitlab/auth/o_auth/user.rb
| jaywalk wrote:
| 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.
| cortesoft wrote:
| Why not just randomly generate it each time, then?
___________________________________________________________________
(page generated 2022-04-01 23:00 UTC)