Unhandled error conditions disclose detailed information #1008

New Issue

tahoe-lafs · 2010-03-27T22:08:47Z

duck commented

2010-03-27 22:08:47 +00:00

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.

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**.<br> 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.

tahoe-lafs added the

labels 2010-03-27 22:08:47 +00:00

tahoe-lafs added this to the undecided milestone 2010-03-27 22:08:47 +00:00

duck commented

2010-03-27 22:26:41 +00:00

Attachment 1008_example1.png (127155 bytes) added

Example 1 of Unhandeled error conditions disclose detailed information in WUI

**Attachment** 1008_example1.png (127155 bytes) added Example 1 of Unhandeled error conditions disclose detailed information in WUI

1008_example1.png

124 KiB

duck commented

2010-03-27 22:26:53 +00:00

Attachment 1008_example2.png (181988 bytes) added

Example 2 of Unhandeled error conditions disclose detailed information in WUI

**Attachment** 1008_example2.png (181988 bytes) added Example 2 of Unhandeled error conditions disclose detailed information in WUI

1008_example2.png

178 KiB

davidsarah commented

2010-03-29 00:38:13 +00:00

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.

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.

tahoe-lafs changed title from ~~Unhandeled error conditions disclose detailed information~~ to Unhandled error conditions disclose detailed information

2010-03-29 00:38:13 +00:00

duck commented

2010-03-29 15:35:28 +00:00

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.

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 commented

2010-03-29 15:59:01 +00:00

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.

Replying to [duck](/tahoe-lafs/trac-2024-07-25/issues/1008#issuecomment-76696): > 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.

tahoe-lafs modified the milestone from undecided to 1.7.0

2010-03-29 15:59:01 +00:00

zooko modified the milestone from 1.7.0 to eventually

2010-06-19 03:35:59 +00:00

zooko commented

2010-09-07 17:22:44 +00:00

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 commented

2010-10-22 14:48:40 +00:00

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:76700.

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

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:76700](/tahoe-lafs/trac-2024-07-25/issues/1008#issuecomment-76700). 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 commented

2010-10-23 00:48:44 +00:00

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

davidsarah commented

2012-04-15 01:25:09 +00:00

#1720 is a special case of this.

Sign in to join this conversation.