GitLab

Created by: safar

Environment description

I have discovered a major security issue when using Shibboleth authentication with GitLab 5.4.0. Think the same issue is still present in latest version if I have interpreted the source code properly. In version 5.4.0 the code resposible is here:

    def find_or_new_for_omniauth(auth)
      provider, uid = auth.provider, auth.uid
      email = auth.info.email.downcase unless auth.info.email.nil?

      if @user = User.find_by_provider_and_extern_uid(provider, uid)
        @user
      elsif @user = User.find_by_email(email)
        @user.update_attributes(extern_uid: uid, provider: provider)
        @user
      else
        if Gitlab.config.omniauth['allow_single_sign_on']
          @user = create_from_omniauth(auth)
          @user
        end
      end
    end

Attack scenario

This GitLab is setup inside multi-domain federation. For example, same person can have an user account in multiple domains. More importantly that user can have the same email value across multiple domains accounts although the Uid will differ.

Person's accounts in multiple domains before login with Shibboleth

	Account created manually in GitLab	Realm1.tld	Realm2.tld
Username	safar_admin
E-mail	[email protected]	[email protected]	[email protected]
SSO Uid		[email protected]	[email protected]
Is admin?	True	N/A	N/A

Shibboleth login using account from realm1.tld IdP

When using user account from realm1.tld IdP which has different e-mail from the user account created manually in GitLab a new user will be created and following message will be shown in application.log: Creating user from shibboleth login {uid => [email protected], name => Name Safar, email => [email protected]}

Shibboleth login using account from realm2.tld IdP (here's the breach)

When using user account from realm2.tld IdP which has the same e-mail as the user account created manually in GitLab I get logged in directly into that manually created account. Since that account has full admin privileges an attacker could change his email adress to '[email protected]' in his IdP's account and get logged in as server's administrator. In our federation users can change their emails associated with their user accounts.

Of course if the attacker knows any other user's e-mail he can change his e-mail and log in as that user.

Proposed solution

Uid AND e-mail should match with manually created accounts when authenticating from outside IdP. Currently it works Uid OR e-mail should match, which is wrong as shown above.