[CRM-16899] System Information Leak: External (CRM/Core/Error.php) Created: 23/Jul/15 Updated: 19/Aug/15 Resolved: 19/Aug/15 Status: Project: Component/s: Affects Version/s: Fix Version/s: Security Level: Closed CiviCRM Core CiviCRM 4.6.5 Type: Reporter: Resolution: Labels: Remaining Estimate: Time Spent: Original Estimate: Bug Chris Burgess Fixed/Completed None Not Specified 4.4.17, 4.6.7 Security - Published Priority: Assignee: Votes: Trivial Nicolas Ganivet 0 Not Specified Not Specified None Documentation Required?: Contributed Code Funding Source (see https://civicrm.org/issuequeue): Description See PDF for full details Summary The program might reveal system data or debugging information in with a call to on line . The information revealed by could help an adversary form a plan of attack.Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack. Explanation An external information leak occurs when system data or debugging information leaves the program to a remote machine via a socket or network connection. In this case system data or debugging information is produced by and leaked by in CRM/Core/Error.php line 337 Comments Comment by Nicolas Ganivet [ 28/Jul/15 ] Well ... this code block is only executed if (php_sapi_name() == "cli") which seems to be a pretty solid test as to php being called from the command line. So there is no information leak 'to a remote machine via a socket or network connection'. Either: we deem this unimportant and delete the debug_print_backtrace() that is causing the issue or we flag this as a false positive with HP (is there a process to do so?) Comment by Chris Burgess [ 28/Jul/15 ] Fair enough! Thanks for looking into this Nicolas. I think we potentially could output something nicer than a backtrace here, eg log error to debug log and print a nice message would seem a "nicer" tool than one which says "That failed, BLAAAARGH". Maybe we output backtrace only if --verbose or similar? +1 removing the debug_print_backtrace() in favour of nicer output +1 it's fair to call this a false positive There's no process to flag as false positive. We just have to discuss with HP directly, which is probably better done in large batches given that email turnaround seems to be 1-2 weeks on their side of the fence. Comment by Nicolas Ganivet [ 28/Jul/15 ] I would personally +1 on commenting the debug output all together (if there is a developer on the other side of the cli they will know how to reinsert it if needed), but let's discuss this with the security team on our next call. Comment by Sunil Pawar [ 29/Jul/15 ] PR : https://github.com/civicrm/civicrm-core/pull/6339 Comment by Tim Otten [ 30/Jul/15 ] I don't like the idea of removing debug output from CLI. When folks send error reports over IRC/forum/JIRA/stackoverflow, we need as much info as we can get. Requiring an extra communication cycle to say "please go hack CRM_Core_Error and get back to us" would suck. There's an alternative helper in CRM_Core_Error called formatBacktrace(). Comment by Eileen McNaughton [ 06/Aug/15 ] don't close this without it being in 4.4 too Comment by Eileen McNaughton [ 11/Aug/15 ] For 4.4 https://github.com/civicrm/civicrm-core/pull/6478 There were lots of conflicts so I hope it's all ok Generated at Wed Feb 10 02:19:08 UTC 2016 using JIRA 6.2#6252sha1:aa343257d4ce030d9cb8c531be520be9fac1c996.