Page MenuHomePhabricator

Possible to make restricted files public on Phabricator via Diffusion
Closed, ResolvedPublicSecurity

Description

Files on Phabricator are always viewable to a user if they are attached to an object that they can view. It seems Phabricator does check if you can view a file before allowing you to attach it. If you don't have access to the file, it will just look like this {F99999999999} in plaintext. It seems Phabricator does not do this check when creating commits in Diffusion repositories. This means you can make a restricted file public simply by including the syntax to attach the file in the commit message which will then by synced to Phabricator, causing the file to be made public regardless of whether you had access in the first place. As file numbers are sequential, it is not to hard to come across a restricted file simply by enumeration (e.g. https://phabricator.wikimedia.org/F34911492).

Example of this occuring here: F21966, the file's policy was set to WMF-NDA, yet it is public by virture of being included in a commit, even though the author did not have access to the file.

I also confirmed this locally as well.

Details

Risk Rating
Medium
Author Affiliation
Wikimedia Communities

Event Timeline

Dylsss renamed this task from Possible to make restricted files public on Phabricator via Differential to Possible to make restricted files public on Phabricator via Diffusion.May 6 2022, 12:09 AM

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?

Dylsss updated the task description. (Show Details)

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.

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

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.

mmartorana changed Risk Rating from N/A to Medium.May 16 2022, 4:16 PM

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

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.

brennen closed subtask Restricted Task as Resolved.Jun 22 2022, 7:31 PM
sbassett added a subscriber: mmartorana.

@Dylsss - Now that this should be resolved with the Gitlab security release (T309430), is there any need to keep this task PermanentlyPrivate?

Resolving under previous assumptions.

sbassett changed Author Affiliation from N/A to Wikimedia Communities.Jul 6 2022, 4:45 PM
sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".
sbassett changed the edit policy from "Custom Policy" to "All Users".