Opened at 2010-03-27T22:08:47Z
Last modified at 2013-01-14T09:08:14Z
#1008 new defect
Unhandled error conditions disclose detailed information — at Version 10
Reported by: | duck | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | eventually |
Component: | code-frontend-web | Version: | 1.6.1 |
Keywords: | wui security privacy anonymity logging error anti-censorship | Cc: | |
Launchpad Bug: |
Description (last modified by zooko)
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.
Change History (12)
Changed at 2010-03-27T22:26:41Z by duck
Changed at 2010-03-27T22:26:53Z by duck
Example 2 of Unhandeled error conditions disclose detailed information in WUI
comment:1 Changed at 2010-03-29T00:38:13Z by davidsarah
- Keywords logging error added
- Summary changed from Unhandeled error conditions disclose detailed information to Unhandled error conditions disclose detailed information
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.
comment:2 follow-up: ↓ 3 Changed at 2010-03-29T15:35:28Z by 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.
comment:3 in reply to: ↑ 2 Changed at 2010-03-29T15:59:01Z by davidsarah
- Milestone changed from undecided to 1.7.0
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.
comment:4 Changed at 2010-06-19T03:35:59Z by zooko
- Milestone changed from 1.7.0 to eventually
comment:5 Changed at 2010-09-07T17:22:44Z by 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?
comment:6 Changed at 2010-10-22T14:48:40Z by zooko
- Keywords tor added
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...
comment:7 Changed at 2010-10-23T00:48:44Z by davidsarah
- Keywords anonymity added; i2p tor removed
Using 'anonymity' as tag for tickets relevant to Tor and I2P.
comment:8 Changed at 2010-12-16T01:44:32Z by davidsarah
- Keywords anti-censorship added
comment:9 Changed at 2012-04-15T01:25:09Z by davidsarah
#1720 is a special case of this.
comment:10 Changed at 2013-01-14T09:08:14Z by zooko
- Description modified (diff)
Example 1 of Unhandeled error conditions disclose detailed information in WUI