Page MenuHomePhabricator

Re-enable stacktraces on Wikimedia wikis ($wgShowExceptionDetails = true);
Open, MediumPublic

Description

Stacktraces are currently disabled on Wikimedia wikis after there were incidents where private data was leaked through arguments. As a result, we now redact all arguments in stack traces by replacing them with their type or class:

#3 /srv/mediawiki/php-1.30.0-wmf.19/includes/deferred/DeferredUpdates.php(210): DeferredUpdates::runUpdate(MWCallableUpdate, Wikimedia\Rdbms\LBFactoryMulti, string, integer)

So now that's in place, can we re-enable stack traces on Wikimedia wikis? I've marked this as a Application Security Reviews . There's plenty of historical discussion behind this (others can probably add more links):

Event Timeline

Which patch used for disabling (moving from true to false)?

In T176533#3632822, @Zoranzoki21 wrote:

Which patch used for disabling (moving from true to false)?

This was before we used version control for wmf config files (its true in original feb 2012 import but gets set to false in may 2012 import a956534)

An interesting thing i didnt know is that test and test2 have public stack traces. I doubt the security implications for enabling it on these test but ultimately still production wikis is very different from enabling everywhere.

Displaying stacktraces/detailed error messages is generally considered an insecure deployment pattern in web application security. I think I understand the logic for wanting to do so, however I don't support it, despite our redaction of arguments. My concern is that that redaction may somehow fail in a critical way, resulting in unintentional exposure of data beyond that which can be gathered by nature of the openness of our project.

Were we to enable detailed error messages, we (not my team, but perhaps yours @Legoktm) would need to document very clearly why it was done, what security controls are in place, etc. because it's going to make us look like we don't know any better and we will get regular reports from independent security researchers pointing out this deviation from well-founded best practice.

The ''well-founded'' adjective is always dubious when it refers to security by obfuscation. Yes, here the privacy leak risk is asserted, but the concern has been addressed.

The question seems more "from the stacktrace, and the different methods called, can an attacker guess information about users?". For example, do we see some attack where different codepaths will be triggered according some privacy information (and so, does the list of the methods called can help to guess something private)?

Displaying stacktraces/detailed error messages is generally considered an insecure deployment pattern in web application security. I think I understand the logic for wanting to do so, however I don't support it, despite our redaction of arguments. My concern is that that redaction may somehow fail in a critical way, resulting in unintentional exposure of data beyond that which can be gathered by nature of the openness of our project.

What's the best way to demonstrate that the redaction is most likely not going to fail? Extensive test coverage? Browser tests? It's impossible to guarantee that some code won't fail of course, so I understand that desire to minimize the attack surface in which private data could get revealed. I'll flesh out the pro reasons to enable this to justify which I believe it outweighs the potential risks.

Were we to enable detailed error messages, we (not my team, but perhaps yours @Legoktm) would need to document very clearly why it was done, what security controls are in place, etc. because it's going to make us look like we don't know any better and we will get regular reports from independent security researchers pointing out this deviation from well-founded best practice.

Sure, I can do that :)

sbassett triaged this task as Medium priority.Oct 4 2019, 5:27 PM
sbassett moved this task from Incoming to Watching on the Security-Team board.