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