Tasks related to enhancing the security of Phabricator.
Sun, Mar 26
Mon, Mar 20
We don't plan to take any other upstream actions here, but let us know if anyone has further questions.
Thu, Mar 16
(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.
Fri, Mar 3
Thu, Mar 2
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.
We could also provide some kind of bin/auth burn-everything-to-the-ground to automate these steps, but I worry that it would almost never be tested (I think it's very difficult to test comprehensively in an automated way) or run, and there's a good chance it might be forgotten about when authentication changes occur.
Ah, you're right. It looks like request data may also have leaked. I'll edit my earlier posts to reflect that. Briefly, the change is: passwords and VCS passwords are potentially at risk.
Has cloudflare explicitly said that only responses were leaked, and never
requests? I recall "POST data" being explicitly called out as showing up in
the leaks, but I can't remember if this was in an official write up or
To cycle passwords, you can do this:
Only our websocket host is behind CF proxies, so I invalidated all auth sessions by changing the security.hmac-key. I wanted to also invalidate all Conduit tokens just as a fire drill but couldn't found a method of doing this.
If you have configured your entire install behind Cloudflare (we do not encourage this in the documentation), you are at greater risk, as anything served by Phabricator could have been leaked. If you believe you are affected and would like help rotating sessions and invalidating credentials, let us know.
Although this problem is severe, the absolute size of the leak appears to be small (my task title is hyperbolic). From the Cloudflare disclosure:
Feb 14 2017
(Or we should just remove CAN_JOIN -- is there any actual use case for read-only rooms? If there is, shouldn't users still be able to join those rooms in order to follow them, just not send messages?)
A related issue is that CAN_EDIT does not imply CAN_JOIN, so users with CAN_EDIT but no CAN_JOIN can get a policy error while trying to join.
Feb 8 2017
I'll make the other adjustments -- str_replace() is the right approach, but this vital production infrastructure could probably use some unit tests anyway.
We are using phabricator-sentry python package to create tickets in Phabricator from Sentry.
They get created, but they don't show up in the the "Recent Activity" view.
Are there any reasons way?
Yes, I just copied a pasted the diff. I was having an issue getting arc working for https://secure.phabricator.com/
Aha that makes sense. Thanks.
My guess is it was a cut & paste diff
Out of curiosity, why are there "Context not available." indicators here? Am I not supposed to see R25 Secure?
Feb 7 2017
I changed some things you requested but I do not have enough knowledge of php to do the other part. Maybe use str_replace? Anyway... feel free to commandeer this and make the change
Let's really AMP THIS UP to the NEXT LEVEL 🚀
Feb 1 2017
Jan 5 2017
Jan 2 2017
Jan 1 2017
libcurl supports SMTP (see https://curl.haxx.se/libcurl/c/smtp-mail.html) and can be used instead, provided that the relevant functions are exposed to PHP. This avoids needing to shell out to an external executable.
Dec 28 2016
From a cursory read of CVE-2016-10045, it seems like PHP may be written in such a way that mail() can not be invoked safely. Silly PHP!
updated advisory; https://legalhackers.com/advisories/PHPMailer-Exploit-Remote-Code-Exec-CVE-2016-10045-Vuln-Patch-Bypass.html
I don't think this changes the plan you suggest, just linking for completeness.
Dec 26 2016
This appears to be the fix: