I reported this at Hackerone: https://hackerone.com/phabricator

Note: A commit does not necessarily have to be merged either, just uploading the patch to Gerrit, syncs it here, e.g. rEFLW5b44de477c315ff30edbb1c7b16b6cc9edf3ed79 which is "unpublished".

Thanks for finding this! As Phacility has ceased operations I'm not sure there will be any outcome from https://hackerone.com/phabricator .
https://we.phorge.it/ might be more effective but I don't know if they have a workflow to create a restricted task there.

Evan Priestley did respond and said that they could not commit to a timeline for fixing because Phabricator is no longer actively maintained, but will try to get to it when they have a chance.

I don't think we actually use this kind of workflow of attaching files to commits, so we can probably just disable attaching files to commits?

Yes, file upload security is not one of Phabricator's strong points. See also: T170080, T75774, T149152, T234585. Thanks for filing the upstream bug.

I also found another way to perform this same type of attack using Calendar ICS import (https://phabricator.wikimedia.org/calendar/import/edit/), similarly, the import seems to be created by a system user, and Phabricator ignores permission checks for files.

I also found 3 other vulnerabilities. Global default settings (https://phabricator.wikimedia.org/settings/builtin/global/) is accessible to all users, but should only be accessible to administrators. This allows an attacker to change some settings for all users, including theme, language, timezones, notifications and email settings.
I also found that workboard triggers (https://phabricator.wikimedia.org/project/trigger/edit/) could possibly allow an attacker to gain access to restricted tasks. This is because the trigger can assign users (which grants the assignee access), but the trigger does not check if the trigger creator can access the task. This means someone could accidentally grant access to an attacker when moving the task on a workboard to a certain column. An attacker can increase the likelihood of this succeeding using projects which are more likely to have restricted tasks (e.g. Trust-and-Safety or WMF-Legal). Triggers can also be created fairly silently, e.g. they don't seem to show up in the activity feed.
Lastly, I also found that Slowvote and Countdown can cause a Denial of Service due to recursive inclusion, when the Slowvote or Countdown object itself is included in its own description. The Denial of Service can then spread to any other object by including the Slowvote or Countdown object on it. If the Slowvote or Countdown object is included in a task, the Denial of Service will spread to the activity feed and the Phabricator home page (e.g. https://phabricator.wikimedia.org) will then fail to load.

I also reported all of these to Hackerone, but as said they might not be fixed anytime soon.

Thanks, @Dylsss, for all of this pen-testing! I've tagged Release-Engineering-Team here as the ostensible maintainers of this Phabricator instance. We could likely work on some patches to address these issues (and perhaps even submit back to upstream) but I'm not entirely certain how feasible that is at this time.

The Denial of Service issue was fixed: https://secure.phabricator.com/rP01253d533bbca72e179b1efb64d97e4d91c988e4.

Global default settings issue is now also fixed in upstream: https://secure.phabricator.com/rP698ada2470b18ae0b6ec579614b56b1bee395eba

Hi @Dylsss, it seems to me that once the file goes public it could be accessed by anyone, even non-phabricator users.
Can you confirm this behavior?

Thanks

In T307750#7924889, @mmartorana wrote:

Hi @Dylsss, it seems to me that once the file goes public it could be accessed by anyone, even non-phabricator users.
Can you confirm this behavior?

Thanks

Yes, that is the case if the object that the file is attached to is also public, if the object policy is set to "all users" then only logged in users will be able to access the file, etc. On the other hand, if the file is attached to an object where the policy is set to just yourself. I.e. using the Calendar application to import an ICS file as mentioned above, where you can adjust the object policy, then an attacker could also access a restricted file without anyone else knowing.

This is now fixed in Phabricator upstream, there is now an advisory at https://secure.phabricator.com/T13683 and change summary at https://secure.phabricator.com/w/changelog/2022.21/. This task has details of the attack that were purposely omitted and undisclosed in Phabricator upstream, so I am temporarily adding PermanentlyPrivate to prevent this task from being made public.

Also is F21966 considered private, as it was previously set to WMF-NDA.

From my understanding of the changes, files can now be unattached but still referenced. This means F21966 can be unattached from here and the commit mentioned in order to be made private again. In addition, I think this also means that some tasks which were previously PermanentlyPrivate due to sensitive file attachments, could be made public, as files could be unattached?

Thanks @Dylsss for your help.
I am glad that the issues are now fixed in the Phabricator upstream. I am now tagging Release-Engineering-Team as they are the maintainers of Phabricator and they can address the issue.

I assume that T309430 will fix this

In T307750#8009866, @Aklapper wrote:

I assume that T309430 will fix this

Can I be added to T309430 or can someone describe what that task is. I assumed the issues described in this task were already fixed when Phabricator was upgraded (except the issue that workboard triggers can give users access to restricted tasks, which isn't fixed upstream, although that's more of a social engineering issue and low risk).

@Dylsss: The task is simply about upgrading to the latest version of phab (2022.21)

@Dylsss - what @RhinosF1 said, but I've subbed you over there anyways.