8 ms·

Critical Gitlab vulnerability let attackers take over accounts

224 points by lelf 5y ago

showerst 5y ago
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 5y ago
  A different comment thread recommending http basic auth: https://news.ycombinator.com/item?id=29761966 https://news.ycombinator.com/item?id=29761966
- czbond 5y ago
  Do internal hosted versions not have auth built in ?
  - 0x0 5y ago
    It keeps the riff-raff away when a new gitlab 0day appears in some obscure public/guestuser visible API
- paxys 5y ago
  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.
nightpool 5y ago
Seems to be a dupe of https://news.ycombinator.com/item?id=30872415 https://news.ycombinator.com/item?id=30872415
ichugwindex 5y ago
The classic hardcoded password
moepstar 5y ago
14.9.2, 14.8.5, 14.7.7 are the patched versions - saved you a click :)
- deleted 5y ago
  [deleted]
- kfrzcode 5y ago
  If you update blindly to these patch versions without actually clicking you may not be the best security operator
czbond 5y ago
My take was this is self hosted gitlab instances, correct?
- Chafouin 5y ago
  Not only, some users in our organization have received an email announcing them the password reset and we are using gitlab.com.
KronisLV 5y ago
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-nexus-and-drone 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 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."?
- anticrisis 5y ago
  For a small team, you could look at fossil: https://fossil-scm.org https://fossil-scm.org. It’s what SQLite team uses.
  - KronisLV 5y ago
    Oh hey, i think there was a post about Fossil here on HN a few days ago: https://news.ycombinator.com/item?id=30815693 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 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/ https://sourcehut.org/
rob-olmos 5y ago
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 5y ago
I got this email for an account that uses the public gitlab.com service.
jaywalk 5y ago
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 5y ago
  Then what’s the use of the password?
  - mikeryan 5y ago
    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/e2fb87ec5d4e235d6b83454980cec9c049849a1c#5c0ba240988a5482dcc1747338da4852f51c668a https://gitlab.com/gitlab-org/gitlab/-/commit/e2fb87ec5d4e23...
    - mikeryan 5y ago
      Oh someone used the test fixture in lib/gitlab/auth/o_auth/user.rb
      - bspammer 5y ago
        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.
  - jaywalk 5y ago
    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 5y ago
      Why not just randomly generate it each time, then?

224 points by lelf 5y ago

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 5y ago
A different comment thread recommending http basic auth: https://news.ycombinator.com/item?id=29761966 https://news.ycombinator.com/item?id=29761966
czbond 5y ago
Do internal hosted versions not have auth built in ?
- 0x0 5y ago
  It keeps the riff-raff away when a new gitlab 0day appears in some obscure public/guestuser visible API
paxys 5y ago
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.

nightpool 5y ago

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

ichugwindex 5y ago

The classic hardcoded password

moepstar 5y ago

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

deleted 5y ago
[deleted]
kfrzcode 5y ago
If you update blindly to these patch versions without actually clicking you may not be the best security operator

czbond 5y ago

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

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

KronisLV 5y ago

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-nexus-and-drone 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 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."?

anticrisis 5y ago
For a small team, you could look at fossil: https://fossil-scm.org https://fossil-scm.org. It’s what SQLite team uses.
- KronisLV 5y ago
  Oh hey, i think there was a post about Fossil here on HN a few days ago: https://news.ycombinator.com/item?id=30815693 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 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/ https://sourcehut.org/

rob-olmos 5y ago

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 5y ago

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

jaywalk 5y ago

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 5y ago
Then what’s the use of the password?
- mikeryan 5y ago
  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/e2fb87ec5d4e235d6b83454980cec9c049849a1c#5c0ba240988a5482dcc1747338da4852f51c668a https://gitlab.com/gitlab-org/gitlab/-/commit/e2fb87ec5d4e23...
  - mikeryan 5y ago
    Oh someone used the test fixture in lib/gitlab/auth/o_auth/user.rb
    - bspammer 5y ago
      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.
- jaywalk 5y ago
  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 5y ago
    Why not just randomly generate it each time, then?