Federal frenzy to patch gaping Gitlab account takeover hole(theregister.com)
theregister.com
Federal frenzy to patch gaping Gitlab account takeover hole
https://www.theregister.com/2024/05/02/critical_gitlab_vulnerability/
18 comments
The way releases are done and security is handled, one can argue that it makes sense to stay one major version behind - as long as it is a version to which security patches are applied regularly.
I follow this rule, or the variant where you wait for the first point release of a new major version, wherever possible. My desktop ran Debian bullseye until maybe about a month ago, when I updated to bookworm on its 5th point release. My browser of choice on that machine is firefox-esr, which is still on the 115.x branch.
I'm updating to bookworm on my daily driver laptop today - testing the full system backup now.
I've had minimal issues recently with debian but decades of debacles (not just debian, everything from RSX-11 to windows server) have made me cautious. So exhausted with wasted time.
I've had minimal issues recently with debian but decades of debacles (not just debian, everything from RSX-11 to windows server) have made me cautious. So exhausted with wasted time.
I've really come to enjoy Debian stable. It's going to take something significant to get me off Bookworm.
> It's going to take something significant to get me off Bookworm.
Do you have experience using "Debian LTS"? It might have gotten me to stick to Bullseye for a little while longer, but I don't know much about it, and EOL was coming along soon.
Do you have experience using "Debian LTS"? It might have gotten me to stick to Bullseye for a little while longer, but I don't know much about it, and EOL was coming along soon.
I have a system running Debian LTS for ~2 years, with Firefox ESR. No complaints, no nightmares. So far it's just working!
My mid-90's boss often repeated his old bosses' sayin "No oh," as in never depend on an initial release, wait for the patches.
> it makes sense to stay one major version behind - as long as it is a version to which security patches are applied regularly
That's why companies offer LTS SKUs.
That's why companies offer LTS SKUs.
GitLab only supports the latest three point releases, so that's not an option here.
> The upshot of all this is that admins who enabled some form of two-factor authentication (2FA) in GitLab are safe and unaffected by the vulnerability. And of course you enabled 2FA, didn't you?
...which begs the question: What US federal agencies aren't deploying their GitLab instances behind CAC auth at a minimum?
...which begs the question: What US federal agencies aren't deploying their GitLab instances behind CAC auth at a minimum?
You would be very very surprised how many federal agencies still use just a pw for vpn etc access to their whole network. Or maybe you wouldn’t.
Basically all of them? Even the DOD Iron bank / repo1 has non CAC modes behind an auth provider. They have forced 2FA on from what I can see now though
Ha, I thought this is about the latest account takeover vulnerability when using Bitbucket OAuth (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-4024), but it's actually still about the old one from January...
My god I read up a little on the vulnerability and it might have been written as a feature to recover your account with any email address?? The module was called RecoverableByAnyEmail or something.
The intention was "any email associated with the user". You submitted an email address, Gitlab looked up the account associated with it, then sent the reset email to the supplied address. The issue was they didn't consider what would happen if you submitted an array of emails.
Not to worry. My company is still on version 15. We stay BEHIND the curve, where it's SAFE.
Gotta avoid those supply-chain vulnerabilities.
[deleted]