I don't currently know enough about kerberos or the claimed attack to know if it is genuine. However, the issue was opened a year ago and remains unaddressed; meanwhile, the last commit to the repository was 5 months ago.
# The internal kerberos_spnego provider is a replacement for# omniauth-kerberos. Here we re-use the 'kerberos' provider name to ease# the transition. In time (in GitLab 9.0?) we should remove the# omniauth-kerberos gem and rename the internal 'kerberos_spnego'# provider to plain 'kerberos' and remove this special method.
From my limited knowledge of kerberos and this attack, looks like it might still be a problem for password-based kerberos sign-ins since the timfel-krb5-auth gem, which omniauth-kerberos depends on, doesn't have a binding for krb5_verify_init_creds() for verifying TGT's that originate from the legit KDC. Attacker would need to spoof KDC responses, and I'm assuming this would over a private network and not across the Internet.
How many customers/users have enabled the Kerberos integration?
@jritchey@nick.thomas The last commit of this gem was 4 years ago, and the same attack is still here, should we do something about this such as switch gem as suggested in the documentation
# The internal kerberos_spnego provider is a replacement for# omniauth-kerberos. Here we re-use the 'kerberos' provider name to ease# the transition. In time (in GitLab 9.0?) we should remove the# omniauth-kerberos gem and rename the internal 'kerberos_spnego'# provider to plain 'kerberos' and remove this special method.
This looks to me as severity2priority2 issue, with cvss, CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. @rshambhuni, please feel free to change the S/P labels if you think otherwise.
I agree with @ogolowinski. Are password-based Kerberos sign-ins still supported? Based on the docs looks like they may not be? I would second the suggestion of removing the gem given the recent experience with DoD.
Regarding the severity of the issue, it seems like Zanarotti attack is very theoretical and I didn't find any real-life exploits leveraging this vulnerability. The attacker needs to be on the local network and be successful in setting up a malicious KDC (in the same network) and trick the vulnerable application into talking to the malicious KDC and get creds that may let the attacker log in. Even then, this MIT blog (see Verifying Credentials section) describes some caveats on what an attacker can/cannot do.
The Zanarotti attack is only a concern if the act of accessing the machine gives the process special access. Thus a managed cluster machine with Kerberos-authenticated networked home directories does not need to call kim_credential_verify(). Even though an attacker can log in as any user on the cluster machine, the attacker can't actually access any of the user's data or use any of their privileges because those are all authenticated via Kerberized application servers (and thus require actually having credentials for the real local realm).
So the success of the attack depends a lot on how a customer's Kerberos environment is configured among other prerequisites required for the attack (mentioned above). I think the likelihood of someone exploiting is low and the impact unclear (given the theoretical nature of the attack). With this in mind, I’m proposing a 5.0/Medium CVSSv3 score (for a worst case scenario with attacker gaining access to some user data). Updating the labels to severity3priority3.
@rshambhuni@ogolowinski I don't believe we ever officially deprecated it or said when we would remove it. But we've been pushing the Kerberos SPNEGO solution for a very long time - according to docs since 8.10 or so. I imagine most customers using Kerberos are on SPNEGO.
We have a dashboard tracking authentication types our customers have configured via Usage Ping - https://app.periscopedata.com/app/gitlab/857665/Manage:Access---Usage-Ping. It doesn't show much Kerberos usage. I don't see any references to Kerberos in the various graphs, except in the very last graph at the bottom. It seems to indicate maybe 40 customers are using it? But I also can't see the underlying query used to make the graph so I'm not 100% sure if we're counting SPNEGO usage in that number, too - we may well be.
Thanks for checking this out @dblessing , I will create an issue to announce the deprecation in %14.2 - actual removal will be in %15.0, to give customers a heads up - Is there any way to identify the 40 affected customers?
I had another look at this issue and I'm updating the S/P labels to severity4 and priority4 as User Interaction is Required from a victim and Availability impact would be None for the attack scenario described above. This is the updated CVSS score. That being said, we should still target removing the gem in %15.0.
@nmalcolm You raise a good point. Since this issue is about the removal of the omniauth-kerberos gem in the next major release, %15.0, and since we have made the announcement ahead of time to alert our customers, it doesn't make sense to do backports on this one (unless security compliance disagrees ). That being said, since the presence of the gem would still make us potentially vulnerable through the Zanarotti attack, I'm inclined to keep the S/P labels for consistency sake and for this issue to not fall off the vulnerability issue dashboards.
Dennis Tangchanged title from omniauth-kerberos gem may be unmaintainted and there are claims it is vulnerable to the "Zanarotti attack" to omniauth-kerberos gem may be unmaintained and there are claims it is vulnerable to the "Zanarotti attack"
changed title from omniauth-kerberos gem may be unmaintainted and there are claims it is vulnerable to the "Zanarotti attack" to omniauth-kerberos gem may be unmaintained and there are claims it is vulnerable to the "Zanarotti attack"
Orit Golowinskichanged title from omniauth-kerberos gem may be unmaintained and there are claims it is vulnerable to the "Zanarotti attack" to REMOVAL - omniauth-kerberos gem may be unmaintained and there are claims it is vulnerable to the "Zanarotti attack"
changed title from omniauth-kerberos gem may be unmaintained and there are claims it is vulnerable to the "Zanarotti attack" to REMOVAL - omniauth-kerberos gem may be unmaintained and there are claims it is vulnerable to the "Zanarotti attack"
@kerrizor Looks like that MR is just for the documentation update announcing deprecation as mentioned by @ogolowinskihere. This issue is to track the actual removal of that gem in %15.0 so I think we should still keep this issue open.
@kerrizor Our Removal process only allows us to introduce breaking changes in major releases (%15.0 being the next one). In !70260 (merged) we announce deprecation. In %15.0 it will be fully removed. This is a placeholder in order not to forget
@ifarkas Brought up a good question today - are we going to remove this completely w/o providing an alternative, or is there an alternative we can provide?
@lmcandrew@m_gill Who would be the best person from engineering to advise on this?
Thanks for working on this @(confidential)! We've removed the Seeking community contributions label to avoid having multiple people working on the same issue.
@bdenkovych Apologies for the delayed response. I was on PTO for the last few days.
I have made this issue public. As you said above, we have communicated the removal of this gem already and AFAIK there are no known real-life exploits leveraging this gem.