Page MenuHomePhabricator

Security Issue Access Request for Zabe
Closed, DeclinedPublic

Assigned To
None
Authored By
Zabe
Jan 7 2022, 4:01 PM
Tokens
"Like" token, awarded by Majavah."Like" token, awarded by DannyS712."Love" token, awarded by Aklapper.

Description

Phabricator Username: @Zabe

Reasons For Request: I currently help maintaining CentralAuth. I also help general to work on unmaintained deployed extensions. I would like to see related security issues so I can help out fixing them. I have filed a few myself in the past.

I have signed a volunteer NDA as part of T297323. I have 2FA enabled for my phabricator account.

Event Timeline

Dsharpe edited projects, added SecTeam-Processed; removed Security-Team.
Dsharpe added a subscriber: Dsharpe.

Hi @Zabe! Thanks for reaching out and thank you for everything you do!

One of the first questions that we look at for a request like this - for WMF staff or anyone else - is if there is a need for the person to have access to all of the security-protected content in Phabricator. In other words, does the requestor really need access to everything? The reason why the bar for granting such access is kept high is because many tasks in Phabricator that are protected contain information that is sensitive, or that can be used to cause damage to our systems or disrupt the projects. As such, leadership's direction to us is to keep the number of people who can view those tasks limited to those who must have it.

As for granting you access to all security-protected tasks in Phabricator for now, we must respectfully decline. That is in no way a reflection on you - that is just us adhering to our "need to know" rule for granting this type of access. For granting access to certain individual tasks in Phabricator, the bar can be lower depending on the task. We should have a more granular way to separate the most sensitive security-related content in Phabricator from tasks that we more freely add people to, but we don't have that capability right now and I am not sure when we will. If we can find a way to implement that granularity, I'll reopen this task and reach out to you.

Are there any specific tasks you need access to today?

@Dsharpe: Given that this is a request by a respected contributor in good standing who has +2 rights in Core (T296165), signed an NDA (T297323) to have Logstash access, wrote 415 patches across many codebases (*) in the last 90 days (351 of them merged) and reviewed 290 Gerrit patches (*) in the last 90 days (which both might be more activity than many WMF engineers who have Security ticket access for reasons which sometimes might boil down to "I work here so I'm tasked to work on stuff and you hand out permissions because I work here"), and seeing the numerous lingering open security issues which likely lack human capacity (also due to the nature of restricted access) and lack of prioritizing in WMF's engineering planning, I'm asking you to either please reconsider this decision, or kindly explain which other reasons our few volunteer contributors who have a great cross-codebase understanding of our systems would have to provide. Thanks in advance for considering.

(*) Note that these two links will only start to show results soon, as I just renamed the database entry from a real name (probably indexed from Gerrit) to "Zabe".

Hi @Zabe! Thanks for reaching out and thank you for everything you do!

One of the first questions that we look at for a request like this - for WMF staff or anyone else - is if there is a need for the person to have access to all of the security-protected content in Phabricator.

Hmm, as a person (one of two or three folks) who helps maintaining CentralAuth, which is reponsible for authentication and authorization on production and has currently no code stewardship, yes imo it would make sence to get access. Security vulnerabilities are sometimes not fixed for a very long time if they are not highly critical.

Random example: T260863: Globally hidden usernames can be enumerated by unauthenticated users by crawling Special:GlobalUserRights with user IDs

^ That issue quite easily allowed generating a list of all globally suppressed users, but no one was around to see that this issue would allow something this severe. Thus, it did not got fixed for 10 months and then it only got fixed because I basically rereported the same issue. Not good.

In T285190#7175269 sbassett told me that there are 'plenty of somewhat dated and forgotten bugs in Phab that deal with similar issues'. That gives me pause. The existence of many partly quite old open sec issues was also meantioned by @Aklapper above.

To be honest, this request is not a rhetorical masterpiece. I would definitely understand if my point wasn't conveyed. CentralAuth is my main motivation here. In addition, there will be similar issues in other extensions, which again like times are not fixed because there are few volunteers with access and it is often not within the purview of WMF/WMDE staff with access.

In other words, does the requestor really need access to everything?

That wording is not good imo. Off course I don't need access to everything, but that applies to (almost) everone. Moreover, whether access to a specific task is needed usually cannot be practically estimated in advance, it would simply be far too much work.

I would also say that the word 'need' is not good itself, especially in the context of a volunteer contributor. This sometimes results in a response that seems a little bit like 'You are doing this in your volunteer time, so you don't need to do this, so you don't need access' (I am not specifically referring to security issue access requests here).

In my opinion, the question that should be asked is if it would be beneficial for the general security of the site to grant access. (Of course, I understand that data protection must not be neglected in the process.)

The reason why the bar for granting such access is kept high is because many tasks in Phabricator that are protected contain information that is sensitive, or that can be used to cause damage to our systems or disrupt the projects. As such, leadership's direction to us is to keep the number of people who can view those tasks limited to those who must have it.

I completely understand, but to be honest, I'm a little disappointed by the distinctions that are made between WMF/WMDE employees and volunteers. If a WMF/WMDE employee says something like 'I need access because I am responsible for this or that extension and therefore I need to fix security vulnerabilities in it', they (almost) always get access.

I also need to agree with what @Aklapper wrote about this:

[...] (which both might be more activity than many WMF engineers who have Security ticket access for reasons which sometimes might boil down to "I work here so I'm tasked to work on stuff and you hand out permissions because I work here"), and seeing the numerous lingering open security issues which likely lack human capacity (also due to the nature of restricted access) and lack of prioritizing in WMF's engineering planning, [...]

[...]
As for granting you access to all security-protected tasks in Phabricator for now, we must respectfully decline. That is in no way a reflection on you - that is just us adhering to our "need to know" rule for granting this type of access. For granting access to certain individual tasks in Phabricator, the bar can be lower depending on the task. We should have a more granular way to separate the most sensitive security-related content in Phabricator from tasks that we more freely add people to, but we don't have that capability right now and I am not sure when we will. If we can find a way to implement that granularity, I'll reopen this task and reach out to you.

Are there any specific tasks you need access to today?

Yes, here are a few:

CentralAuth related: T112359, T112320, T201568, T226212, T234371, T237274, T244682. There are quite a few more, but I am too lazy now to start gathering task ids (I would need to ask users with access just in order to get them), since I often don't know them.

T284873 since it is quite related to the work I do at T291994/T274817.

T294713, if it hasn't already been fixed (should be related to T293368).

Also T277919 and T294713, each if not yet closed (both should be somewhat related to issues like T25310/T293368).

kindly explain which other reasons our few volunteer contributors who have a great cross-codebase understanding of our systems would have to provide

Andre is basically asking for more detail than the current "at the discretion of the Wikimedia Security Team" statement on https://www.mediawiki.org/wiki/Security/SOP/Access_to_Phabricator_Security_Issues.

@Zabe I added you as a subscriber to all of the Phabricator tasks you listed above that you weren't already subscribed to. Are there any more you need to see?

For those with access, the procedure for granting access to security-protected content in Phabricator is on Officewiki in "Granting Access to Security Content in Phabricator". That procedure is in accordance with how leadership wants the process to work currently. Also, leadership is the one suggesting carving the most sensitive security- and privacy-related content in Phabricator off to address the problem here.

@Dsharpe: Could you please elaborate who exactly is "leadership" so they could be contacted? Thanks.

@Zabe I added you as a subscriber to all of the Phabricator tasks you listed above that you weren't already subscribed to. Are there any more you need to see?

For those with access, the procedure for granting access to security-protected content in Phabricator is on Officewiki in "Granting Access to Security Content in Phabricator". That procedure is in accordance with how leadership wants the process to work currently. Also, leadership is the one suggesting carving the most sensitive security- and privacy-related content in Phabricator off to address the problem here.

Actually yes, could I also get access to T287630 (related to invalid cross-wiki accesses), T121037 (related to T226212), T169097 (related to T292594) and T298361 (CentralAuth related)?

@Dsharpe sorry for bothering you another time. But could I also get access to T287625, it is also related to T287630/T298223 and my work at T291994? Forgot to include it in my last comment.

@Dsharpe could I get access to T179900 (related to T104500), T277428 (related to T277919), T262969 (related to T144097), and T196386 and T207580 (both related to renaming (came up after T194204))?

@Dsharpe could I get access to T183212 (related to T207580) and T235006 (related to T112359)?

@Dsharpe could I get access to T207576 (related to T209760) and T91917 (related to T72910)?