Secret task titles revealed in project workboard


#1

Observed Behavior:
This is security relevant as sometimes already a task title contains sensitive information.

If somebody creates a task with a very restrictive view policy but tags the task with a workboard-enabled project, the task title is revealed in the workboard to everyone who can view the project.

Workaround is to restrict the view policy of the project but this is very ugly, as we actually want people to see the tags of a task instead of having the UI full of “Restricted Project” tags.

Expected Behavior:
The view policy of the task should be respected by project workboards and also print “Restricted Task” like all the other UI does. Maybe the tasks shouldn’t even be displayed there if the user doesn’t have the rights to view the task anyway?

Phabricator Version:
phabricator 201c56a91ee5764aaacfbce2c0ad7a5822a7c852 (Fri, Apr 20) (branched from 33da9f833fdd6bbf2d1ade40acd091f4a9f0ac76 on origin) arcanist 23f199bf180758e99b9d5ac604777cbd90d0e507 (Fri, Apr 20) (branched from ad3087e5e151e4b5f5fb39cc6846039fc4f7018f on origin) phutil f3e10579f640ebad648c56f677164647ab7251a4 (Sat, Apr 14) (branched from 20eff1c8d14f08f05ef72828fa379e871d29662c on origin) diff 3.3 at /usr/bin/diff git 1.8.3.1 at /usr/share/phabricator/support/bin/git hg Not Available pygmentize 1.4 at /usr/bin/pygmentize svn Not Available

Reproduction Steps:
Create a task with a restrictive view policy but tag it with like a publicly visible, workboard-enaled project. Log out and visit the workboard. The title of the task is revealed.


#2

This is a very serious security issue if it works as described. If possible, please support security issues like this via our HackerOne program: https://hackerone.com/phabricator

Reporting via HackerOne helps us manage disclosure and response better and allows us to award you security bounties.

However, I can not reproduce this issue. Here’s what I did:

I created a task, “Secret Task”, and set the visibility to just me:

I created a project, “Non-Secret Project”, and set the view policy to “Public”:

I viewed this project’s workboard as:

  • Me (who can see the project and task)
  • Another user (who can see the project, but not the task)
  • An anonymous/logged-out user (who can see the project, but not the task)

Here’s what each user sees:

Me:

Another user (can not see the task):

A logged-out user (can not see the task):

These results look correct to me. The expected behavior is that the task will not be visible on the workboard for users who do not have permission to see it, and that’s the behavior I observed.

Can you give me more details about how to reproduce this issue? In a setup like the above, if any user other than “hector” can see the title “Secret Task” via any means, it’s a serious security problem that violates the policy model.


#3

Geez. Of course I’m not able anymore to reproduce it. A colleague showed it to me a few weeks ago when I asked him why he panic-changed the visibility of many projects overnight. I’ll ask him him again if he can still reproduce this issue and report back here! Sorry, should have checked again before opening this thread. It’s a short week in Germany, might take a few days…


#4

Can’t be reproduced anymore. Here are more details in case it is still of interest and never was consciously fixed: back then we double checked the issue with two different browsers on two different PCs, as well as private mode to eliminate browser caching as the source. The setting was exactly like yours: Task only visible for task author on publicly visible project workboard. The title was also revealed in the project history. All we can do for now is to assume that it has been fixed meanwhile. The issue was noticed on the 17th of March and we’re up-to-date with the stable branch most of the time, sometimes a week behind.


#5

I strongly suspect there’s something we missed in the reproduction instructions and that the observed change in behavior is not a result of a change in behavior in the upstream.

Phabricator’s entire query/policy architecture is focused first and foremost at making this kind of bug very difficult to write (see also: https://secure.phabricator.com/T13133), and this would be among the most serious security issues in the product, ever, if it reproduced.

I retested with the 2018 Week 10 code (March 9th) and the behavior is identical to what I observed above.