Page MenuHomePhabricator

Potential misassociation of Git/Gerrit username and LDAP username
Closed, ResolvedPublicSecurity


Ref T315897: Jobs started failing on on 2022-08-21, does this mean that in cases where people use different Gerrit/Git (user)names to their LDAP (user)name, someone could register a wikitech account with that (user)name and cause issues?

I'm not sure what those "issues" would be mind you, so this could well be a nothingburger — unfortunately y'all are the people to make that call 😅

At the very least if we judge this by T315897, something somewhere would "associate" the result of a check against LDAP user TheresNoTime with a commit of user Samtar — this feels suboptimal?

Inversely, could someone set a Gerrit/Git (user)name to a privileged LDAP user, and in the above case have a commit "associated" with them?


Risk Rating
Author Affiliation
WMF Product

Event Timeline

sbassett added subscribers: bd808, sbassett.

@TheresNoTime - Thanks for filing this. I'm definitely not a subject matter expert on wikitech, but looking at what is likely the relevant config and some past, quasi-related bugs (T259746, T168692, T218526, T171417 et al), I'm not seeing any obvious spoof-checking for similar/related usernames when compared to either renamed or deleted accounts. So yes, I think some of the attacks you describe are theoretically possible but potentially very unlikely. For example, Git/Gerrit username creation is forced through wikitech account/shell creation. So I don't believe there's an easy way for users to change that without updating their wikitech account or having some sleeper account at the ready which happens to be similar enough to a renamed or deleted wikitech user. I think it might be a good idea to put this in front of Release-Engineering-Team and maybe @bd808 to weigh in on the feasibility of such theoretical attacks in relation to wikitech and Git/Gerrit's current configuration.

sbassett triaged this task as Medium priority.Sep 2 2022, 8:34 PM
sbassett changed Author Affiliation from Wikimedia Communities to WMF Product.
sbassett changed Risk Rating from N/A to Medium.
sbassett added a project: SecTeam-Processed.

Wikitech has all of the "normal" anti-spoof things enabled in the MediaWiki config as far as I know. The wikitech.php config file linked to in T316029#8209256 is a set of very special extensions for wikitech's config that are loaded during normal CommonSettings.php processing.

I don't fully understand what's going on in T315897: Jobs started failing on on 2022-08-21, so I don't think I can offer a valid opinion on the security implications at this time. As far as I understand it there is some code running on a Jenkins server that a very small number of people actually have any visibility into (e.g. I can login there, but then get served a page with a big "Access Denied" heading and no meaningful content or links). This code raises an exception after loading an LDAP record based on a username lookup. That exception is happening because the cn (or uid?) used to do the lookup belongs to a record that is also marked as disabled. The disable was intentional (T302109: Delete "theresnotime" LDAP account), but I have no real understanding of why Jenkins is doing the lookup in the first place.

sbassett lowered the priority of this task from Medium to Low.Sep 6 2022, 6:09 PM
sbassett moved this task from Incoming to Watching on the Security-Team board.

That exception is happening because the cn (or uid?) used to do the lookup belongs to a record that is also marked as disabled. The disable was intentional (T302109: Delete "theresnotime" LDAP account), but I have no real understanding of why Jenkins is doing the lookup in the first place.

@TheresNoTime - Would you be able to provide an explanation or context for the above? It seems like the upstream Jenkins bug mentioned in T315897 was fixed via a patch @hashar submitted and should be included within an upcoming Jenkins release per T315897#8208556. So that specific issue will hopefully be resolved soon.

The issue came from the Jenkins Git plugin. When processing the git changelog it does some heuristic against the author field which would look like: James Bond <>. To attach that entry to a user known to Jenkins, the plugin asks for for a user James Bond or a user having the name theresnotime extracted from the email. The later leads to a disable user in Jenkins. James Bond can still send a patch cause their login is samtar with whatever arbitrary email they have configured. That works fine with Gerrit.

Then the upstream plugin only handled user not existing errors and raised an exception for any other user lookup failure (such as a user disabled in LDAP). The fix has been merged upstream and T315897 is pending a new version of the plugin to be created.

I don't think there is any security issue, the Git author looked up is only to link the commit author/committer to a user in Jenkins. We do not use any permission based on that.

sbassett closed this task as Resolved.EditedSep 13 2022, 5:30 PM
sbassett claimed this task.
sbassett moved this task from Watching to Our Part Is Done on the Security-Team board.

Ok, thanks for the additional analysis, @hashar. I'd agree that the pending deploy of the upstream patch and what Jenkins actually seems to be doing with the git author data/lookup, there likely isn't a vulnerability here.

I think this task can be resolved now. @TheresNoTime - any issues with making it public on your end?

Glad to see this was nothing :) feel free to make it public!

sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".Sep 13 2022, 5:35 PM
sbassett changed the edit policy from "Custom Policy" to "All Users".