Readit News logoReadit News
sarki_247 · 2 years ago
(GitLab Team member here) You can learn more about the disclosure from GitLab, the security releases made and the recommended actions at https://about.gitlab.com/releases/2024/01/11/critical-securi...
maxnoe · 2 years ago
How does the attacker introduce the controlled email as secondary email of the user they want to take over?
nemoniac · 2 years ago
Am I missing something or does the security release recommend updating to the latest version without saying what that latest version is (at time of writing)?

Come to think of it, how can you find what version of Gitlab is being run? (through the web interface on a CE instance)

upon_drumhead · 2 years ago
It says it three times in the first three sections.

For example

> Today we are releasing versions 16.7.2, 16.6.4, 16.5.6 for GitLab Community Edition (CE) and Enterprise Edition (EE).

adamjb · 2 years ago
>how can you find what version of Gitlab is being run? (through the web interface on a CE instance)

It's up the top at gitlab.example.com/help

declan_roberts · 2 years ago
> GitLab doesn't support SMS-based 2FA – the most commonly hijacked implementation – only supporting app-based 2FA or that issued via a WebAuthn device, which are much more secure.

I’m glad the register is calling this out. I hate handing over my personal phone number to a website for my “security”. Yeah right security, and not for your anti-spam and tracking purposes.

App-based 2FA is much better, especially passkeys.

czbond · 2 years ago
For Self - hosted Gitlab instances
dfc · 2 years ago
...that do not use LDAP.
NoZebra120vClip · 2 years ago
Several years ago, I informed GitLab and a few other services that their MFA implementation was faulty. Any user with control of the designated email address could reset the password on an account without knowing that password.

GitLab and the others told me that this was not a vulnerability, because that is not part of their threat model after all.

mgbmtl · 2 years ago
Isn't that a usability vs security trade-off? Asking naively as a non-expert here.

In some systems, a password reset lets you bypass MFA. On Gitlab, however, you might be able to reset the password, but it will not let you bypass MFA (which was a nice mitigation for this CVE).

I often wonder about this, because people's email should have fairly good security (MFA, detect new devices, suspicious IPs, alerts, etc), and MFA on the other service lets them have similar protections. Both services might not be bullet-proof, but an attacker will likely generate alerts in one or the other.

Most of my users are very non-technical, and might not have access to their MFA (MFA reset requests are fairly frequent), so to be able to access using a one-time-secret sent by email seems like an acceptable compromise, especially if it means that more users will enable MFA. In systems I administer, less than 20% of users tend to enable MFA (it depends on org policy, and it's often optional).

Speaking of, I wish services would do auth by: login -> MFA -> pass, instead of login -> reCaptcha -> pass -> MFA. Especially for scenarios where MFA is mandatory. Having reCaptcha is really annoying considering I went the extra step of enabling MFA (ex: Stripe, Quickbooks).

sebmellen · 2 years ago
Without a capchta it is possible to iterate through all possible backup codes.
JimDabell · 2 years ago
> Any user with control of the designated email address could reset the password on an account without knowing that password.

Do you mean without having the MFA code? Because literally every password reset implementation operates without you knowing the password; that’s the entire point of it.

ChrisMarshallNY · 2 years ago
I guess that a service like GitLab might need to take this seriously, but ones with a lesser attack surface, might not care.

This is the case for the service that I am about to release. It makes it very convenient for users that forget their passwords. I know many instances of users not using services, because they forgot the passwords, and the services make it difficult to reclaim their accounts (Google, for instance).

Too much security can be a killer, for many applications. We don't need Fort Knox security for many apps.

In our case, we make sure that we don't require any user data, beyond a simple email address (and have Apple's private relay enabled, for those that want a bit more security). For many app developers, keeping so little user data is anathema, as they are actually PID harvesters.

em-bee · 2 years ago
absolutely this. for most services i WANT to be able to recover access with only my email address. if i forget the password for a service, then most likely i also lost whatever additional security codes i have been told to save somewhere.

i have half a dozen backups of all the ssh keys i use because i am scared to loose them. the chance that someone gets access to one of those backups is probably more likely than them breaking into my email. ok, they would still have to find the password for the ssh keys. my point is that the risk to loose something that i can't keep in my head is greater than such a breakin. when i set up 2FA for github or gitlab i am going to plaster that 2FA app on as many devices as i possibly can to mitigate the risk that i would loose one of those devices which could permanently lock me out.

how likely is it that an attacker can take over my email?

they would have to break into my laptop, and take over my browser and break into my mail server. or they would have to spoof the DNS for my email domain.

are there any threats i am missing?

akerl_ · 2 years ago
This seems pretty normal? If you've forgotten the password, you reset it via a reset email. If you had MFA set up, you still need the MFA with the new password. To reset the MFA, you either log in with a recovery code or you contact support.

Most services I use operate this way.

canadiantim · 2 years ago
Isn’t the point of resetting a password that you don’t know the password?
huggingmouth · 2 years ago
Sure, but then you can't call it mfa.
acheong08 · 2 years ago
Here is the commit in which this was fixed: https://gitlab.com/gitlab-org/gitlab/-/commit/abe79e4ec43798...