Tasks related to enhancing the security of Phabricator.
Thu, Apr 13
(And I think "Conpherence as an announcement tool" is a very marginal use case anyway -- today, Phame is probably better already?)
That seems reasonable to me. We could implement a "read-only" equivalent later by having a flag like "require edit permission to send messages to this room" if we need it. That probably makes more sense anyway -- I can't really think of any use cases where a room is sort-of read-only, but the users who can post to it are different than users who can edit it.
I think we should remove the CAN_JOIN. If you can see it, you can join it. I don't see any parallel in Slack and looks like there are mods that add it forceably by kicking you off a channel if you leave a message. lulz.
Mon, Apr 10
T12531: Unable to upload file: failed to read 4583864320 bytes after offset 0 discusses one side effect of these changes, it should be fixed in HEAD of master and stable now.
I think this is, to at least some degree, a legitimate security problem. Consider:
Thu, Apr 6
(That said, the hash cost may become very relevant when we eventually ship "Phabricator Valuable Golden Coin Money", our blockchain-based virtual currency.)
I get these rough per-hash costs locally (Macbook Pro), with a 64-byte key:
Piece of info (you guys might already be aware of it) which might be of interest when implementing this; SHA512 is often faster then SHA256 on x64. See for example: https://crypto.stackexchange.com/questions/26336/sha512-faster-than-sha256
Some guidance about "configure captchas if you're a public-facing, password-login install" would be good here too, but maybe we should just raise it as a setup issue if you have password auth enabled, and let users ignore it if they're VPN'd.
In the future, please report security issues via HackerOne: https://hackerone.com/phabricator -- notably, this allows us to award you a security bounty if you discover an issue.
Wed, Apr 5
I'm maybe going to try to do this in the short term:
Thank you for explaining - I didn't mean to imply I thought it was a security concern, as it is very clear what giving someone Edit access means.
T4721 (which I also linked on the HackerOne report) discusses usability improvements to Passphrase, including better documentation and hinting about this use case and possibly the separation of the "Can Use Credential" and "Can View Secret" policies. These are reasonable usability concerns.
It sounds like the user is confused that having View access doesn't let them have access to decrypt/see the secret - only that they can use the secret within Phabricator. So in order to allow others to decrypt/see the secret he gives them Edit access which does give them the ability to change the secret.
Thanks for the response Evan.
You can review the HackerOne report, including my response, here:
Thu, Mar 30
Mar 26 2017
Mar 20 2017
We don't plan to take any other upstream actions here, but let us know if anyone has further questions.
Mar 16 2017
(You could also pipe the list into bin/remove destroy --force, equivalently.)
You can re-run the migration explicitly with:
We ran the script provided above to get an audit of at-risk files. Afterwards we upgraded our instance and the upgrade succeeded however its attempts to delete the affected files failed. The failure is due to using a local file store which is accessible to our web service account but not the phabricator phd services account (T4752). After correcting the file permissions so both accounts have appropriate access, running upgrade again doesn't seem to remove the files.
It is likely that the vulnerable code predates significant portions of the Files and permissions systems, and was just overlooked as these other systems upgraded and gained more powerful policy and permissions capabilities.
The fix is now available on master (rP7626ec0c) and stable (rP6f879559). I've upgraded this install without incident. Per above, note that upgrading destroys evidence, so you should plan any audit or response actions you want to take before upgrading.
Mar 3 2017
Mar 2 2017
Closing this since there doesn't seem to be any thing left that's actionable for us.
Feb 24 2017
Broadly, there is nothing Phabricator could have done differently to anticipate or prevent this issue.