https://bugs.openldap.org/show_bug.cgi?id=10155
Issue ID: 10155 Summary: Invalid [aka FUZZ] -F and -T options can core dump ldapsearch Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs@openldap.org Reporter: doug.leavitt@oracle.com Target Milestone: ---
A customer reported core dumps in ldapsearch which has been tracked to the the improper use of the -F and -T options.
The customer confirmed removing the invalid -F and -T options from their script eliminated the core dumps.
The CLI arguments of the failing ldapsearch look like:
ldapsearch <good CLI args> -F , -T u <good filter and attr args> The good CLI args include proper uses of -H... -x -D ... -w ... -b ... -s ... The good filter and attrs are also valid CLI inputs.
The "bad" args are <sp>-F<sp><COMMA><sp>-T<sp>-u<sp> The -u is also valid but it is consumed as a directory name of -T
From man page and code review the the -F argument is supposed to be a valid URL. and the -T argument is supposed to be a valid directory
The core file output indicates that main calls free after the search takes place. The location is believed to be here:
1658 if ( urlpre != NULL ) { 1659 if ( def_urlpre != urlpre ) 1660 free( def_urlpre ); <--------- 1661 free( urlpre ); 1662 } ... 1672 tool_exit( ld, rc ); ...
This is the first example of the use of -F we have seen so it is unclear how this should be fixed.
But code review of ldapsearch.c and common.c exposed a few weaknesses that could help in addressing the issue.
Observed weaknesses:
The getopt processing code for -T does not check that the arg is actually a directory and fail/error when bad input is provided. Perhaps at least an access(2) check should be performed?
It is unclear if -F should only accept file:// URLs. The existing code does not sufficiently check any URL format instead it processes the argument by looking for the first '/' [no error checking] and determine the remainder to be a tmpdir location similar to the -T argument. So, Fuzz input of <COMMA> seems to eventually lead to the core files.
It is unclear if -F and -T should be mutually exclusive or not.
It seems like the fix to this issue is to add better error checking and to fail on FUZZ inputs. I defer a solution to upstream as it probably requires project direction I lack.