Unhandled error conditions disclose detailed information

[duck]

A number of verbose error messages, including stack traces, are displayed to users of the WUI when an unexpected error condition is encountered.

Vulnerability issue and impact

Detailed error data could be useful to attackers and maybe be confusing to users of the system. Confused users have a higher chance of making security mistakes.

Difficulty to exploit: low.
Penetration tests typically rank this class of vulnerability as medium risk.

Resolution recommendations

Do not include detailed error messages when an unexpected error is caught and return to the user. Rather return a generic error message, that doesn't give any sensitive information to the user. Log details of the error condition to a log file for later investigation.

This is part of a cluster of tickets including: #562, #563, #685, #1008, #1720, and #1904.

[duck]

Example 1 of Unhandeled error conditions disclose detailed information in WUI

[duck]

Example 2 of Unhandeled error conditions disclose detailed information in WUI

[davidsarah]

In practice I haven't seen the tracebacks reveal sensitive information, although I agree that it's difficult to be sure that they never do. This isn't coincidence; it's partly because what is on the stack for a particular request, normally pertains only to that request. It may contain information that has been obtained (directly or indirectly) using caps provided with the request, but it is only giving this information to a requestor who had those caps anyway. That combined with the fact that the gateway and storage servers are operating with least authority, means that they don't have much sensitive information to leak. So I believe the assessment "Difficulty to exploit: low" is inaccurate.

For the usability issue, see #971, which asks for the traceback to be hidden (but available) for all WUI errors.

In any case, the full nevow traceback has been incredibly useful in diagnosing some previous bugs; I'd be loath to lose it as a debugging tool.

[duck]

My concern is for the anonymous network usecase. For the regular Internet this usually isn't a problem (unless you want to pass PCI audits).

The stacktraces disclose the installation location, which is often within a users home directory. This will show their username and effectively end their anonymity as node operator.

For me this means you shouldn't open up the WUI in an anonymous network if you value your anonymity.

[davidsarah]

Replying to duck:

My concern is for the anonymous network usecase. [...] The stacktraces disclose the installation location, which is often within a users home directory. This will show their username and effectively end their anonymity as node operator.

Good point.

We should probably have an option in tahoe.cfg to omit the stacktraces (or perhaps a single option to enable anonymous operation). I wouldn't be confident that we can sanitize them.

[zooko]

What's the next step on this ticket? Write a unit test which sets the "anonymous" bit in the cfg file and then triggers and exception and gives the code a red flag if the exception contains the username?

[zooko]

Okay, just to be clear, we have davidsarah's approval that it would be good to create a new config option in tahoe.cfg which toggles between "more debugging information is shown to the user of the wui/wapi" or "less identity-revealing information is shown to the user of the wui/wapi". If you are letting someone else use your wui/wapi server, but you don't want to expose a lot of little details about your system to them such as the path names of the Python source files, then you should set it to the more private option. If you are the only user of your own wui/wapi, or if you would rather give more debugging information to your users, then you should set it to the more informative option (which is the default setting).

Since davidsarah is +1 on this, and since I am +0, and since nobody else (such as Brian Warner or Kevan Carstensen) have spoken up to say they are minus on this, then the patch should move ahead.

Therefore, the next step is for someone to write a test along the lines of what I suggested in comment:5.

Also, I just noticed that this ticket is currently tagged with the "i2p" tag and the "privacy", but not with the "tor" tag. This issue is the same for both the i2p and tor anonymity services, and so it should probably be tagged with both or neither of their names. For now I'll add "tor", but maybe we should change to just using the "privacy" tag to indicate issues which are of interest to any such privacy-sensitive deployment...

[davidsarah]

Using 'anonymity' as tag for tickets relevant to Tor and I2P.

[davidsarah]

#1720 is a special case of this.