[go: up one dir, main page]
Skip to content

Project import can be used to mass probe emails

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Problem

When importing a project with all members users are detected by their email. That creates an opportunity to mass probe emails on gitlab.com

The feature is currently working as intended, but we can improve it as a defence in depth measure.

Currently any user who can import a project could create an import that contains a single email / hundreds of / thousands of email addresses as members, in an attempt to validate which email addresses map to users. The import code would match this against the primary email, which a user could consider private.

Malicious actors on .com do not need to go via support (source), and this abuse case applies to self-hosted too. The process is noisy though: "victims" can notice they're added to a group, and notify GitLab's anti-abuse team if it hasn't been spotted already. (Compared to API endpoints, for example, which are easy to call without the "victim" noticing).

We also currently have an open, public issue about email privacy which discusses these types of issues, so it is not a secret.

Steps to reproduce

  1. create a project on your localhost with 1000 members with public_email = potential emails you want to probe
  2. export the project
  3. import it at victims instance (e.g. gitlab.com). You'll need someone with admin rights for that.
  4. existing accounts with emails from the list of 1000 emails will be added as project members.
  5. attacker gets a list of valid emails from project members list

Notes

Imported users can be mapped by their public email addresses on self-managed instances, if an administrator (not an owner) does the import.

Proposal

  1. Focus this issue on the addition of rate limiting, treating it as a security enhancement as we have in the past. We can remove the typebug ~vulnerability tags (and sev/priority if appropriate), and add typefeature.

  2. Create an additional issue to discuss a potential change in how we look up users, again as a typefeature.

Both can be addressed on canonical (and/or in docs). Since this topic is publicly discussed elsewhere, both can be made public.

Edited by 🤖 GitLab Bot 🤖