It doesn't try to run evil.exe until I edit the cell (the csv version, and the modified xlsx I saved myself try to start on opening).

Here's a version with =cmd|'/C evil.exe'!A0 if that produces different results:

Actually, Excel 2016 is vulnerable. The test case is incomplete. The cell needs to be =cmd|'/C evil.exe'!A0 to trigger the issue.
By modifying the value in both the xlsx and csv files, I was able to blindly click yes on lots of warning prompts and start calc.exe. But I am not sure that modifying the value in the xlsx file is giving the same result as the export would (something may have been stripped off in the meantime...)

It seems an up to date patched Excel 2016 is not vulnerable.

Saving this file as csv also doesn't trigger the bug in Excel 2016 - on reopening, Excel misdetects the format as SYLK, warns about the extension not matching, then warns that an error occured during loading, and finally when you agree to continue loading as "a different format", it opens without running calc.exe or prompting to update cells.

Good to hear, thanks!

Checked on Excel 2016 and it didn't run calc.exe or prompt for "update cells". Also checked on Excel for mac~

If anyone actually has bona fide Excel.exe installed, you could try opening this file to double check that we're not currently vulnerable:

T11632 is vaguely related.

(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.

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:

(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.

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:

(This was incorrectly closed by the text "doesn't actually fix T8918" in rP08de131da525.)

We don't plan to take any other upstream actions here, but let us know if anyone has further questions.

(You could also pipe the list into bin/remove destroy --force, equivalently.)

You can re-run the migration explicitly with: