657256 - Traceback enabled. Information Disclosure (e.g. system path)

Status: RESOLVED DUPLICATE of bug 319140

(Bugzilla :: Bugzilla-General, defect)

Description

[Luca Carettoni]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110422 Ubuntu/10.04 (lucid) Firefox/3.6.17
Build Identifier: bugzilla.mozilla.org current version

The application does not properly handles exceptions. Traceback is enabled thus an attacker can retrieve system details (e.g. webroot path).



Reproducible: Always

Steps to Reproduce:
1. Visit https://bugzilla.mozilla.org/page.cgi?id=bbb

Actual Results:  
Application stack trace is shown:

Traceback:

 at /data/www/bugzilla.mozilla.org/page.cgi line 78
	ModPerl::ROOT::Bugzilla::ModPerl::ResponseHandler::data_www_bugzilla_2emozilla_2eorg_page_2ecgi::handler(...) called at /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/ModPerl/RegistryCooker.pm line 204
	eval {...} called at /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/ModPerl/RegistryCooker.pm line 204
	ModPerl::RegistryCooker::run(...) called at /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/ModPerl/RegistryCooker.pm line 170
	ModPerl::RegistryCooker::default_handler(...) called at /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/ModPerl/Registry.pm line 31
	ModPerl::Registry::handler(...) called at /data/www/bugzilla.mozilla.org/mod_perl.pl line 138
	Bugzilla::ModPerl::ResponseHandler::handler(...) called at -e line 0
	eval {...} called at -e line 0


Expected Results:  
Generic error message

Comment 1

[David Lawrence [:dkl]]

Resetting to upstream as this is not necessarily a BMO issue. 

Reason is that page.cgi uses ThrowCodeError and not the more user friendly ThrowUserError. Technically it is a code error as most people do not manually fill in the id= part of the URL and is instead created by different parts of Bugzilla. But this is not consistent as other places such as attachment.cgi for action= uses ThrowUserError instead. 

One possible solution would be to update ThrowCodeError to use CGI::Carp instead and post stack traces to the web server error log and not the browser. Or make this all configurable by a data/params setting that sets a debug level so that for production systems, the level could be set to 0 or high for a devel system.

dkl

Comment 2

[Gervase Markham [:gerv]]

If an attacker getting the output of a ThrowCodeError is a useful thing for them, then it seems to me that the right fix is to make ThrowCodeError less useful. Trying to fix Bugzilla so an attacker can never get it to throw a CodeError sounds like a tall order to me!

I think a "debug" param for Bugzilla is an excellent idea. I'm sure it could be useful in several ways.

Gerv

Comment 3

[Frédéric Buclin]

This is intentional, see the discussion in bug 319140.

Comment 4

[Gervase Markham [:gerv]]

Max WONTFIXed that bug, but he did file bug 382394, which is on the debug param I mentioned. Perhaps the way through is to fix that bug and make this behaviour dependent on the param. dkl: fancy doing that? :-)

Gerv

Comment 5

[Max Kanat-Alexander]

The stack trace is not a security issue; I have no problem with it always being on. I made sure that the stack trace doesn't show arguments.

Comment 6

[Luca Carettoni]

From the security perspective, information disclosure via application errors is an issue. Revealing system data helps an adversary to better understand configuration details. In this case, as an absolute path is shown, it can facilitate directory traversal attacks.

Comment 7

[Max Kanat-Alexander]

(In reply to comment #6)
> From the security perspective, information disclosure via application errors
> is an issue. Revealing system data helps an adversary to better understand
> configuration details. In this case, as an absolute path is shown, it can
> facilitate directory traversal attacks.

  Yes, we understand that, but we feel that that argument sounds like security through obscurity, which we don't support or believe in.